It never meant anything outside Google or huge orgs. Everyone else is running cargo cults.
An SRE role was my first job at Google in 2006. It was a product of its time and place. Google could hire the sort of full stack programmer/sysadmin types that the article talks about because they had enough clout and desirability at that time that they could get very skilled programmers to give up programming and do sucky on-call work instead. Even then, just two years after IPO and receiving glowing press everywhere, they struggled with this proposition. A typical strategy (which worked on me) was to promise that whilst they wouldn't offer a job as a developer right away you'd be able to transfer out of SRE after a few years. Another strategy was to build teams that consisted of mixes of sysadmins and developers. In other words, even back then in the most optimal hiring environment possible, there were very few people who were genuinely both developers and sysadmins in one neat package. There was always a clear bias towards one or the other.
The hiring process was nightmarish for both sides. SRE had a higher rejection rate than SWE with only about 1% of candidates getting an offer; the accept rate was lower. Hundreds of interviews to get one person through the door. I had to do eight interviews that covered everything from TCP to obscure bash puzzlers, simultaneous equations, C, performance debugging, Python and CS algorithms. All of us had to spend enormous amounts of time running interviews as a consequence, and there was a constant shortage of SREs too, meaning many services were being administered and on-call covered by SWE teams instead. Who then grumbled a lot because that wasn't what they'd signed up for, of course.
I think if you're not in a similar situation as Google in 2006 then the SRE role isn't going to make sense for you to try and hire. It's a unicorn role. There just aren't enough people out there who have skills that span such a wide gamut of topics. The fact that she put up an ad for SRE and got "a bunch" of "ops monkeys" is the least surprising thing in the world. Of course that happens. Unless you're willing to interview hundreds of candidates to get one hire, whilst simultaneously running a dragnet recruiting operation, then you'll have to compromise. Even Google had to compromise.
DHH isn’t always right, and his “you only need a server” mantra isn’t true for everyone, but IMO it is DEFINITELY true for nearly any startup that’s shown sustainable growth. By all means, use cheap cloud resources when you have minimal revenue (unless you already have someone who can administer Linux). But after that? Run a couple of boring servers and front then with a load balancer. You don’t need multi-regional HA at that stage, so don’t worry about it.
"Can't we simplify the human bodies, so that we can crank out doctors after a two years bootcamp rather than 10+ years of med school and specialization?"
The answer is no.
Just think of how many different flavors of SQL there are being run. If we can't even all agree on that, I have doubts that we could unify on the rest.
For simplifying, yes probably, but it's hard. For instance relational databases require quite a lot of skill to run, even if you pay for a managed cloud DB. The cloud operator will handle some work like backups but some other problems like schema migrations, sudden query plan changes etc can still trip you up in production. To simplify that away you need a fundamentally different approach, maybe something like FoundationDB and Permazen. But then of course you lose a lot of the features that make people want the RDBMS engines.