>Are you certain that business systems are written by people who know all three of these things? My conjecture is that most practising business programmers will tell you that "libraries" and "frameworks" exist to solve these problems for them and that knowledge of the details is nice to have but not necessary for employment as a business programmer.

Are there programmers who write business applications without understanding and knowing these things? Yes, most certainly. Are these programmers working in businesses known for using software as a competitive advantage? Almost certainly no. With the exception of AWS, most of what Amazon does (and what made them successful initially) was business software: e-commerce, shopping carts, payments processing. Yet it's clearly that they used in-house software development talent as a competitive advantage (most obvious example is Dynamo's original role as a shopping cart engine which allowed them to handle peak holiday traffic without declining sales).

Libraries and frameworks are great, but they're of no use if the application developer doesn't know they need to use them. An app developer will have to know that Double can't give him precise decimal math, before he'll use BigDecimal. An app developer will have to know what race conditions are before he'll know where to use a ConcurrentHashMap vs. a HashMap vs. a synchronized block vs. ReentrantLock. I'm not aware of an ORM that is sophisticated enough to tell you what sort of index to use (this may also be an omission on my part and there may be ORMs and other tools that will make reasonable default choices and setup indices during the DDL phase).

>"Systems/library/algorithm implementation work" is another thing entirely, but I'm sure we can agree that at this moment in time, there are very few people doing systems work or building libraries compared with the number of people using them to build business systems.

My perception is somewhat skewed: I'm in Silicon Valley and have worked at multiple Internet firms and at an infrastructure (security) vendor as a systems/library implementer (or you can say, "mostly userland systems programmer"). While it's obvious that there's lots of systems work going on in infrastructure vendors, I'd say that least 50% to 75% of engineering in established Internet companies and lead start-ups in that sphere involves building tools, libraries and implementing/fine-tuning algorithms rather than application-level programming. The application developers drive the demands for these tools/libraries/algorithm implementations and thus have to have more than "black-box" level familiarities with them. Very rarely are people also hired just for application development roles: knowing a specific library/framework well won't get you hired, as that may not transfer over to other positions in the company. If you look at the interview processes in these companies, you'll quickly see that they reflect that. The app to infra development ratio will certainly be different at smaller startups (more app, less infra), but the need to hire generalists with strong knowledge of the fundamentals is even greater.

tl; dr Let me say it again: good programmers should know the fundamentals. This doesn't just go for the systems/infrastructure developers, but product developers as well: you may still be able to get a job without knowing these basics, but you'll be "locked out" of the most lucrative jobs in a given industry (or even out of whole industries).