The analogy I like to use when discussing the Art vs. Engineering paradigm in programming is architecture (the wood & steel building sort, not hardware chip instructions) design. Every architect, whether building a private home or an office complex, needs to know certain fundamental facts about the materials they use (load bearing capacity, for instance) and the choice of what materials are used is (typically) dictated by the intended purpose of a building. Brick and wood framing is pretty universal, but you don't generally see homes being built out of little more than tin siding and steel frames like factory warehouses, or giant glass walls like skyscrapers.
That part -- mating the materials with the intended purpose -- is the "art" in architecture. The "art" in programming (aside from some limited domains like UX or AI) is less immediately describable except by effect (e.g. "How quickly do new team members get up to speed?") but should be no less important to any project manager. I don't really think that programming has been around long enough for us to have our Frank Lloyd Wright moment, but that is no reason to ignore the "intangibles" and immeasurable aspects to quality code.