It's not that the idea of elegance and simplicity is a wrong idea. It is very difficult to achieve, yes.
Which effectively makes it useless (or impracticable) for the wast majority of projects - it can be several times and finished with standard approaches in the time needed to find really elegant solution.
My point is: if you are a far-sighted IT manager, filter out the ones that just don't cut it (the ones who will never learn because they lack talent, dedication, interest, intelligence, whatever...) Then define the priorities correctly: focus on creating quality software. You, on the other hand, seem to advocate hiring just about anybody and letting them do whatever they please - as long as they eventually can get the damn thing to work... Unfortunately, that's what often happens, and the results are usually just pathetic. A simple project (simple for any good SE) would often turn into a nightmare - with no end in sight. In my own experience, it takes significantly less time and effort to deliver elegant software to QA and Production than delivering a patchy, poorly-designed mess. ALWAYS. In fact, the latter, most often turns into never-ending projects. Bad programmers start coding first, think later. It's because they are constantly in the state of panic. They doubt their ability to deliver anything ever - in the first place. So, they are always in a hurry to show some - any - results. They skip the design (the thinking) part! Proper designs (elegant, clean, simple) don't work for people who should not be programmers in the first place. Everyone else must be taught to do the right thing, and they will soon see how efficient the process becomes. I am amazed that you are arguing with this! I usually see this kind of resistance from the people who try to justify their incompetence, but I can tell that you are clearly NOT one of those people. Perhaps, it's just the "hobby" you've mentioned that makes you do that...
Of course, that brings us to the real problem: many "programmers" should be, in fact, doing something else instead of programming. This is a very unfortunate consequence of the mass-production software phenomenon you have mentioned. Since we can't solve the problem once and for all, it is up to individual IT managers (many of whom are just as incompetent to know better) to identify the good candidates, pay them what they deserve, and get their project done without glitches. The companies that don't do such selection will [continue to] suffer the consequences: the buggy software, never-ending projects, working in the fire-fighting mode late ours and weekends - on things that could have been successfully delivered by just a few good SEs, really fast, and for much less money than the organization blows on the project developed by the "average" SEs using the "standard approaches."
A couple of years ago I was hired by a huge insurance company to work on a system previously developed by another [well-known] consulting company in a course of a year. They had paid that consulting firm ~$1M to develop that system. (Small peanuts for my client...but about $1M too much for the kind of product that was delivered.) When I arrived, the local programmers had been working on bug fixes for that system literally every day. Something would break every single day. It was a continuous sustaining effort, a full-time job for the IT department. Then the company needed to add support for a couple of new (but similar) products to the system and asked me to look into it. It turned out that the system was hard-wired to work only with the original set of products, and any small tweaks would result in the whole thing all but falling apart. Not to mention, the code was atrocious, incoherent, with just plain mistakes that indicated that the programmers didn't understand some of the very basic things about Java, programming, or architecture. I redesigned and completely implemented - from scratch - the whole system, in just over two months. It went into QA, and for the first 2 weeks they had found no bugs! I know, it is unusual, and normally I do expect QA to find bugs in my code, but this was an easy project to me.) Later the client called a couple of times with requests for minor adjustments. That's it. If I had done that project from the very beginning - not that other consulting firm, all it would have taken is a few months at a fraction of cost. Instead, the client paid my cost + $1M, and wasted a year, plus a bunch of grief having to deal with everyday bugs whose fixes produced more bugs every day... I am sure that those lousy programmers who wrote the original version also would justify their crap with time constraints, requirements that were not clear, deadlines, and other external factors that would make "clean" design "unrealistic." It's all nonsense! It is always just an excuse incompetent people use. Anyone who is competent, who is capable of producing quality software will tell you that thoughtful, elegant, and clean solutions always ensure a faster delivery. They also ensure minimal maintenance costs throughout the life-cycle of the software.
I hope we are done discussing this...