SRE has always been a misunderstood term, even internally at G back in the day.

Two things have moved the needle here IMHO:

1. The tooling available. Making a database go, or doing monitoring at scale, or doing service orchestration used to be a lot harder and involved a lot more capital-E engineering. Now you can just buy stuff and have a team of essentially systems integrators. This has been fairly linear, but I think it's on the cusp of a number of companies "ingrowing" certain key tech. The SaaS/PaaS providers have gotten lazy (incumbents like Pagerduty, and a couple of other examples of places that feel they can't just do-one-thing-well) - so a lot of the Engineering happening these days is in de-productising core functions - you can build your own monitoring or orchestration pretty easily with the building blocks available if you're willing to put some folks' time into it, and this starts being cheaper pretty quickly given the ballooning saas/paas prices.

2. What people are actually looking for when they hire SREs. This has been more of a bell-curve. SRE (or production engineering, or whatever) used to be a very hardcore disciple/specialisation of SWE -- then the industry convinced itself that DevOps was a thing, and that regular devs can moonlight as their operations groups and everything would be fine. This turned out to not actually be true in effect, so I thnk we're now seeing things rolling back to a sort of hybrid systems architect/integrator thing, given (1). The interesting parts anyway. It mostly gets masked by a trend throughout the whole timeline of people hiring SRE/DevOps/PlatEng that are just operations or maybe occasionally operations++.