Действительно ли это - плохая идея разработать и разработать бэкенд приложений Python и затем когда-то законченную попытку применить GUI к нему?

Это зависит от проблемного домена. Инструмент для обработки изображений будет довольно сложно реализовать без обращения к графическому интерфейсу. Впрочем, для большинства приложений я бы сильно поспорил в пользу разделения двух частей. Намного, намного легче разрабатывать, тестировать и развивать внутренний интерфейс без использования UI. Это значительно перевесит затраты на определение чистого API между передней и задней частями. Фактически, процесс определения API в целом приведет к лучшему дизайну

IMHO, это было бы лучше. Держать базовую бизнес-логику не привязанной к пользовательскому интерфейсу - это лучший подход, при котором мы можем больше беспокоиться о базовой логике, а не слишком зацикливаться на интерфейсе.

В то же время, важно также иметь некоторую базовую конструкцию интерфейса, чтобы он помогал вам иметь представление о том, какие входы и выходы задействованы, и чтобы базовая логика поддерживала широкий диапазон входов/выходов или просто широкий диапазон интерфейсов.

Так как вы новичок в программировании GUI, ваш подход идеально подходит. Скорее всего, в результате вы получите менее чем оптимальный пользовательский интерфейс, но пока это нормально. И на самом деле, есть несколько очень успешных многомиллионных коммерческих проектов, которые строятся таким образом.

Возможно, лучший подход - это сначала спроектировать пользовательский интерфейс, так как это самая важная часть. После этого вы можете создать бэк-энд, который будет поддерживать этот пользовательский интерфейс. Этот подход все еще приводит к разделению фронт- и бэк-эндов, но делает акцент на потребности пользователя, где он и должен быть.

Разделение пользовательского интерфейса от кода движка - это unixy способ сделать это, и в этом есть немалая заслуга. В результате получаются модульные программы и код повторного использования, которые могут хорошо играть с другими программами и вписываться в большую инструментальную цепочку.

Сказав это, такой подход, как правило, снижает ценность создания действительно удобного для использования пользовательского интерфейса. Внутренняя модель программы очень сложно и редко совпадает с пользовательской моделью, когда сначала разрабатывается функциональность программы, а затем пользовательский интерфейс. В результате, после самостоятельного создания необходимо согласование импеданса с двумя сторонами. Это приводит либо к созданию компромисса в удобстве использования (ваш ui становится не более чем внешним интерфейсом к переключателям командной строки, которые берет ваша программа), либо к большому слою клея между пользовательским интерфейсом и основной программой, который имеет тенденцию быть грязным и ошибочным.

Если ваша программа в первую очередь разрабатывается для запуска через пользовательский интерфейс интерактивно с пользователем, то, вероятно, имеет смысл проектировать пользовательский интерфейс параллельно с вашими фактическими функциональными возможностями.

Итак:

Было бы лучше написать программу знакомым мне способом, а затем применить к ней wxPython gui после того, как я буду удовлетворен общим дизайном приложения

Если ваш пользовательский интерфейс является основным средством работы с вашей программой, то этот пользовательский интерфейс является частью дизайна программы. Нельзя нарисовать что-то над программой, когда она закончена.

Какой уровень интерактивности вам нужен? Если вам нужна богатая обратная связь и взаимодействие, то вам нужна модель OO-программы, тогда вы можете добавить GUI поверх объектов.

Если у вас есть только фильтры и функции (нет реальной обратной связи, или просто окно результатов), то лучше библиотека или компонентная модель.

В любом случае, вам лучше кодировать свою логику отдельно от GUI, так что вы сможете тестировать ее проще.

Если вы привыкли к подходу с большей командной строкой, это была бы плохая идея. Реакция на пользовательский ввод - это совершенно другая парадигма, и вряд ли вы получите ее правильно в первый раз.

Если вы просто говорите о разнице между wxPython и другим графическим интерфейсом, то не беспокойтесь об этом.