В итоге выяснилось, что употребление goto -- дурной тон
А потом выяснилось, что некачественная (в пределе - ее отсутствие) инкапсуляция данных и операций - тоже дурной тон, и ровно по той же причине :)

Ну, структурное программирование как раз и не отрицает инкапсуляции, наоборот. К сожалению, ограниченность ресурсов, которая бывает в дешёвых микропроцессорных системах, не позволяет провести инкапсуляцию "до дна". Приходится держать довольно большой массив глобальных переменных. Искупается сокращением количества "программистов".

{+}

Ограниченность ресурсов крайне слабо относится к инкапсуляции. Инкапсуляция - свойство языка, а машинный код (и его требования к ресурсам) в общем случае не изменяется.
Например, простое добавление модификатора static к описанию статической переменной в файле на Си делает эту переменную невидимой снаружи того же объектного файла, и является простейшим приемом инкапсуляции. Но машинный код с появлением этого модификатора не изменится ни на байт.

Насчет сокращения числа "программистов": от языка программирования наличие кавычек вокруг этого слова не зависит. Программисты - это прежде всего специалисты по выражению задач из предметной области в способ решения этих задач на машине. Многие задачи предметной области лучше (лаконичнее, проще, и в конце концов безошибочнее) описываются не в тех терминах, которые близки к архитектуре машины. Для таких задач нужны дополнительные слои абстракции, так как в их отсутствие их элементы придется изобретать заново в конкретном проекте, совершая все ошибки. "Наиболее эффективный способ реализации некоторых проектов, скажем, не используя язык Лисп: разработать что-то похожее на интерпретатор Лиспа и решать задачу уже на нем". Банковские приложения тоже нужны, и разрабатывать их лучше с использованием EJB, поскольку в противном случае придется реализовать все основные службы EJB самостоятельно.

Другой вопрос - это кадровая политика. Нет смысла брать на работу в низкоуровневый embedded-проект людей, которые по складу ума более годны для высокоуровневой работы, и наоборот.

Я с Вами совершенно не согласен по многим затронутым Вами вопросам, но, увы, сейчас у меня нет времени Вам ответить подробно.
Коснусь только "программистов". Как Вы поняли, это для меня самый ненавистный сорт людей. Я люблю инженеров. Инженер может решить любую задачу, в том числе, и программируя ЭВМ. "Программист" же просто не в состоянии понять, что требуется, а сосредоточивается на самом процессе программирования.

Я с Вами совершенно не согласен по многим затронутым Вами вопросам, в том числе и по переменным static, но, увы, сейчас у меня нет времени Вам ответить подробно. Просто, мне кажется, что Вы не представляете себе, что означает словосочетание "ограниченные ресурсы".
Коснусь только "программистов". Как Вы поняли, это для меня самый ненавистный сорт людей. Я люблю инженеров. Инженер может решить любую задачу, в том числе, и программируя ЭВМ. "Программист" же просто не в состоянии понять, что требуется, а сосредоточивается на самом процессе программирования.

Просто, мне кажется, что Вы не представляете себе, что означает словосочетание "ограниченные ресурсы".
Это понятие, как и любое, введенное человеком, можно трактовать по-разному. В рамках данного обсуждения, в применении к обсуждению "затрат ресурсов на синтаксические и архитектурные рюшечки", для меня ограниченные ресурсы - это, упрощенно, 512-4096 байт ОЗУ и 8-128К программного Flash. То, что ниже (скажем, когда все ОЗУ - это 32 регистра, и стека вообще нет) - действительно может потребовать принципиально другого подхода, но там и уровень сложности доступных для решения задач позволяет со сложностью просто не бороться.

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

Пример того, для чего программист-системщик нужен: стоит на Мурманском шоссе недалеко от Питера два комплекса, наш и конкурентов. Проекты одного уровня сложности и в чем-то даже перекрывающиеся по функциональности. Недели три назад была сильная гроза. Оба комплекса получили по сбою, но аппаратура уцелела. Однако, у конкурентов сбой сразу стал отказом, а наш всего лишь не прошел периодическое самотестирование и автоматически перезапустился еще до того, как нам дозвонились о проблеме.
Резюмирую вышесказанное: программист-системщик - это инженер по сложности и смежным вопросам. Он занимается в числе прочего и задачами надежности, в том числе обеспечением того, чтобы сбой не становился отказом. Думаю, излишне говорить, что "просто инженер, заодно еще и программирующий" вряд ли нормально обеспечит это - он просто не будет знать ни о наличии проблемы, ни о типовых путях ее решения. В каждом деле нужны специалисты. Что, конечно же, не отменяет необходимости знать смежные области и быть способным решать часть проблем самостоятельно - к примеру, я, программист, вполне могу на равных обсуждать и править P-CAD-овскую схему железки с нашим аппаратчиком, или, к примеру, собственноручно спаять себе домой программатор, не бегая для этого в цех, а наш программист-гуевщик со знанием дела обсуждает со мной сетевые протоколы и способен указать на проблему в них.

P.S. диалог становится флеймом, так как спор идет о сферическом программисте в вакууме. К тому же, мы вряд ли убедим друг друга в чем-то - мы просто разный смысл вкладываем в одни и те же понятия, и Вы называете программистами тех людей, которых я программистами не считаю.