I think you're asking a far more general question than you realize about things like professional standards, bodies of knowledge, what is or should be considered canon or foundational, how a curriculum should be constructed, how training programs should work, whether or not specific careers should require licenses, how they should be given. This doesn't apply only to software developers. If you're going to end up being a vascular surgeon, do you really need to know or understand anything about physics and chemistry? Does a contract lawyer need to know anything about legal theory or criminal law? Should a prison warden study ethics and social theory? Should a homebuilder learn about materials science and Newtonian static dynamics? A skyscraper builder? A bridge builder? Where exactly lies the divide between researcher and implementer? Engineer and hacker? Engineer and technician? Technician and hobbyist? Should someone who is good enough to make something themselves that basically works on the happy path be allowed to advertise and sell what they create to others? Should that practice be regulated at all and, if so, how? Most professions have better, widely-agreed upon answers to these questions than software development because they have existed for longer.

I would personally say there is definitely no answer to "what should all programmers know" other than at least one programming language along with its associated tooling and enough about a platform software can run on to deploy it. Beyond that, across the full spectrum of software lifecycle careers, I'd say we've started converging on somewhat of a hodgepodge depending on role and where the standards are coming from. IT technician type careers have various certifications coming from platform providers like Cisco, Redhat, and Microsoft, and industry groups like CompTIA. Corporate security gets things like CISSP. If you go to a university, majors in computer science will give you what we expect academics in the subject to know before they can run labs or teach, and software engineering majors some idea what we might expect team leaders in large software organizations to know about how more general engineering principles and practices get applied specifically to software. These tend to have a lot of commonality in terms of at least being familiar with the basics of operating systems and networking, information security, discrete math, data structures and algorithms, programming language paradigms and constructs, possibly some bit of how compilers and maybe processors work.

Then you get what large and well-known employers expect implicitly from their interview and promotion processes. This seems to have also converged largely on at least including basic common programming language constructs, data structures and algorithms, and possibly some minutiae related to specific languages, toolchains, platforms, ecosystems, and possibly larger principles related to things like distributed systems, databases, how the Internet and web work, depending on the nature of the major product lines.

No single person needs to know all of that, but if you do, you're probably reasonably well-prepared to understand the hows and whys of any well-known or largely-used software system. It definitely doesn't mean your daily life as a developer will ever involve directly using that knowledge any more than a practicing psychiatrist remembers and can recite the exact details of the Krebs cycle. But having to learn it still might help guard a bit against susceptibility to bullshit quackery from drugmakers trying to tell them a miracle cure can do something that is metabolically impossible.