Not only is the work extraordinarily financially valuable in many cases, software is actually pretty hard to do _well_. It's based on highly specialized knowledge and experience. It requires sustained, high levels of discipline and effort. And it is often tedious and/or frustrating work in practice.
It's a corollary to the Dunning-Kruger effect: don't assume programming is easy for _everyone_ just because you happen to be good at it.
I think "Chapter 1: The Tar Pit" of the venerable _Mythical Man Month_ (https://archive.org/details/MythicalManMonth) speaks to this in terms that are still applicable even after half a century. Here are some of the challenges Brooks describes:
1. "Most have emerged with running systems — few have met goals, schedules, and budgets. Large and small, massive or wiry, team after team has become entangled in the tar. No one thing seems to cause the difficulty — any particular paw can be pulled away. But the accumulation of simultaneous and interacting factors brings slower and slower motion. Everyone seems to have been surprised by the stickiness of the problem"
2. "One must perform perfectly. [...] If one character, one pause, of the incantation is not strictly in proper form, the magic doesn't work. Human beings are not accustomed to being perfect, and few areas of human activity demand it."
3. "Other people set one's objectives, provide one's resources, and furnish one's information. One rarely controls the circumstances of his work, or even its goal. In management terms, one's authority is not sufficient for his responsibility."
4. "The dependence upon others has a particular case that is especially painful [...] He depends upon other people's programs. These are often maldesigned, poorly implemented, incompletely delivered, and poorly documented. So he must spend hours studying and fixing things that in an ideal world would be complete, available, and usable."
5. "[D]esigning grand concepts is fun; finding nitty little bugs is just work. With any creative activity comes dreary hours of tedious, painstaking labor [...] [D]ebugging has a linear convergence, or worse, where one somehow expects a quadratic sort of approach to the end. So testing drags on and on, the last difficult bugs taking more time to find than the first."
6. "The last woe, and sometimes the last straw, is that the product over which one has labored so long appears to be obsolete upon (or before) completion. Already colleagues and competitors are in hot pursuit of new and better ideas. Already the displacement of one's thought-child is not only conceived, but scheduled."
I think it's notable that even with five decades of global-scale investment in this field we haven't really _fixed_ any of these challenges. Our tools and practices have improved, certainly, but at best in proportion to the increasing demands of scope/scale/complexity. Context-aware, cloud-connected, toolchain-integrated IDEs with features like programmatic refactoring, REPL-like interactivity (or whatever other modern tooling you'd like to point to) are a giant step up in both usability and productivity compared to the batch processing of literal punch cards workflow that Brooks based his observations on. But I suspect those "woes" still resonate with most people involved with software development today. Projects still regularly fail to hit scope, schedule or budget. Small, obscure errors still sometimes lead to catastrophic failures. Reliability continues to be expensive to and is often fleeting.
The global system of systems that comprise the modern "technology infrastructure" is an ever-expanding, ever-shifting, frequently-unreliable and increasingly-critical house of cards. It's almost certainly the most sophisticated and complex artifact that humanity has ever produced. It's easy for those of us with significant interest, aptitude or experience with it to forget that. But this shit is _hard_. It's a wonder that it works at all.
Toward that end, while you can wave your hands around "how [little] work it takes to become [a programmer]", the fact is it takes a substantial amount of time and effort (and an moderately uncommon degree of aptitude) to become a competent one.
Are some software engineers over-compensated? Probably. But the difference between software engineering and medicine (for example) has less to do with the degree of specialized knowledge or level-of-effort required and more to do with credentialing and our ability to evaluate competence. You can take a 6-week "coding bootcamp" and call yourself a "programmer". You can't take a 6-week first-aid course and call yourself a "doctor". But they are both pretty far removed (in terms of experience and learning) from even a competent "journeyman" in their respective fields (say, a "principal engineer" and "resident", respectively - i.e., someone you could trust to take on a non-trivial level of critical responsibility with relatively little oversight).
To be fair the stakes are generally higher for a typical doctor than for even the most "senior" software engineers, but there's plenty of literally life-or-death software applications, both direct (e.g., medical diagnostics, 911 calling infrastructure, GPS, computer vision) and indirect (even something as mundane as network availability or the reliability of data search and retrieval). Not to mention the enormous number of systems for which failures in delivery or at run-time can have a substantial financial impact. I can't really speak to relative compensation: I imagine many doctors should probably be paid more and many programmers could probably be paid less (and the med-school/residency pipeline should almost certainly have a more sustainable work/life balance). But it's foolish to think that the upper-ish tier of software engineers (say, 40th+ percentile maybe?) doesn't represent a skilled, specialized, and therefore valuable labor force.
It's no surprise that there's a large number of highly compensated software engineers. There's a lot of extraordinarily valuable (from a financial perspective) work to be done and it takes substantial knowledge, experience, and aptitude to be able to do it well.