Mylisz się ~teer. Autor jest prawdziwym programistą. Programistą a nie rzemieślnikiem. Wykorzystanie tak rozbudowanej struktury do rozwiązania tak banalnego problemu jak ten przytoczony w artykule to jakieś jaja. Autor doskonale dostrzega zalety wszystkiego o czym piszesz jednak w przeciwieństwie do Ciebie wie kiedy te rozwiązania stosować, a kiedy nie. Programista to człowiek który umie rozwiązać problem, opracować algorytm jego rozwiązania, często nie koduje, tylko tworzy schematy działania aplikacji finalnej. Gość, który wie jak używać narzędzi programistycznych i klepie finalną postać kodu zwie się koderem i często nie jest w stanie rozwiązać bardzo prostych problemów algorytmicznych. Innymi słowy koder potrafi zabić muchę używając skomplikowanego 30-tonowego działa, programista wie, że tą muchę można równie skutecznie uśmiercić przy pomocy kapcia.

~luk, kompletnie się z Tobą nie zgadzam. To jest spór światopoglądowy - podejście "hakerskie" (w dobrym tego słowa znaczeniu) kontra podejście biznesowe. Patrząc na to z punktu widzenia "hakera", chcącego samemu kontrolować każdą linijkę aplikacji - masz rację. Parząc z punktu widzenia biznesu - ja mam rację.
Ja się zwyczajnie nie zgadza z tezą zawartą w artykule - takie podejście nie jest błędem, jest jedynie wyborem innej drogi. IMO artykuł świadczy o niezbyt przemyślanym stosunku jego autora do narzędzi mających usprawnić proces tworzenia aplikacji. Wbrew pozorom logika opisywanej aplikacji to zapewne kilkadziesiąt linijek kodu wykorzystujących dobrodziejstwa framework'u - rzecz łatwa do napisania i utrzymania. Zaryzykuję nawet stwierdzenie, że o wiele łatwiejsza do utrzymania i o niebo bezpieczniejsza od metody, którą proponuje autor artykułu. Komplikacja struktury jest pozorna - programistę interesuje tylko logika aplikacji, framework to czarna skrzynka.
Piszesz o bardzo romantycznej wizji tego, co uważasz za "prawdziwego programistę", pomijając biznesowy aspekt problemu a prawda jest taka, że jest on w dzisiejszych czasach niepomijalny i również składa się na część tego, co nazywamy "byciem programistą". To naturalna droga rozwoju branży. Języki wysokiego poziomu, paradygmaty programowania realizowane na poziomie semantyki języka, środowiska zarządzalne, wzorce projektowe, frameworki - to kolejne kroki ewolucji. Można ich nie zauważać, ale na dłuższą metę to droga do przegranej.