Beauty is in the eyes of the beholder. It's the result that matters... When you look at a painting, do you really care what kind of brush the painter used to paint it? How silly would that be to tell Raphael that if he used different brushes his paintings would be better? Would his paintings be as good as they are if, instead of following his own path, he would worry about what other painters do?
Interesting analogy. With all due respect, let's dig a bit deeper.
Art is SUBjective. Artists don't get sued if their painting "doesn't work", now or in the future. The consumer either likes it or they don't.
But Engineering, including code, is OBjective. It can be measured to "work" or "not work". People can be held liable if their code doesn't work, even if that isn't discovered at time of purchase. So unlike artists, Engineers and their employers (should) have a tremendous vested interest in making sure that their code works - and if it's found to NOT work, that it can be quickly and easily fixed by whomever is available.
Now let's consider support. A painting is a solo effort. There isn't a team coming along in a few months or years to "fix" it or add features. The consumer either likes it as-is, or they don't. Today, tomorrow, forever.
But Engineering, including (perhaps especially) code, often has people coming along later to "fix" it or add features. When there's a problem, the employer and the customer are *extremely* interested in resolving it as fast and as inexpensively as possible. That means two things: 1) There is great advantage to using tools that decrease the likelihood of bugs in the first place, and 2) there is also great advantage to using tools that make it as easy as possible for utter strangers to later pick up the code, grok it quickly, find, and fix the problem.
Do downstream "users" of art care about the brushes or the paint? No. But if art were Engineering, they'd care a lot. Example: I recently read an article about matching interior and exterior house paint colors. Paint stores have spectrometers now, so you'd expect a perfect match every time, right? What could possibly go wrong - we're using SCIENCE! And yet the consumers - DIY'ers and professional painters alike - were reporting frustration in the field. The article revealed that what happens is the paint *base* formula is sometimes changed, with the result that the optical absorption spectrum changes too. And this means that the perceived color changes depending upon the type of light source. You can match an old and new color in any single given light (say, incandescent) but when illuminated in sunlight they'll look different. Fluorescent and LED have their own emission spectrums and yield other, different results. Unless you keep an indefinite supply of the same base, and the same pigments, it's likely impossible to match existing paint... you just can't replicate the recipe.
Brushes and paint are the "language" of art, but that language can go extinct as soon as the painting is finished. An artist can literally mix his own paints and build his own brushes, and when he (unilaterally!) declares the project finished he can cavalierly destroy all of his tools without risk. Code doesn't have that freedom. To put it in art terms, your code "painting" has to be objectively without error as judged by people you may never meet personally, and then supported, understood, corrected, and extended by strangers whose background you don't know and can't predict. Those strangers have to be able to understand AND duplicate your paint bases, your pigments, your brushes, and your "style" (architecture) at some indefinite point in the future, probably under intense pressure from their employer and its customers. If art were like Engineering, a painting would have to come with a lifetime supply of base... pigments... maybe even the brushes used. But art has the luxury of being subjective. (Yes, there are art restoration projects, but I daresay those folks would side with the concept of NOT using obtuse and opaque tools! Talk about a nightmare.)
OK, I'll stop extending the analogy. In short, art doesn't have to worry about being measured or providing support. Code does. A wise software author plans for this in advance and chooses his tools and architecture to be the easiest to read, understand, debug, and extend. And as a personal request: He also includes at least one line of comment next to every line of code, dagnabit!!!
We're not time-traveling mind-readers, lend us a hand, will ya?