The presence of a "reliability engineer" raises the question of what the hell all the other engineers are there for.

They are there to build features. Hopefully those features are something that solves business problems and ultimately drives revenue. Reliability is a requirement for a useful business system but is not a useful thing on its own. Your system needs to solve actual problems with software features to be useful. That is what the rest of the developers are rightly focused on.

"Operations Engineer", for example.

The term SRE espouses a philosophy that when SRE has done its job perfectly, there is no operations work because the system is reliable on its own.

If you're looking for members of that school of thought, you say SRE. If you're comfortable having a "boiler room" and just need to staff it up, the terms sysadmin and devops work just fine depending on the level of coding involved.

I dig a little bit before commenting (SRE vs DevOps), but SRE as an abbreviation is ugly and reliability is assumed for every subject or role, so, it's redundant.

SRE is about engineering systems to be reliable, which is certainly not a goal taken seriously by default. In a traditional environment the system itself is not reliable and not trying (very hard) to be; rather, the combination of system + pager-carrying operators is reliable.

Many more people are paging operators to do DB replica promotions by hand, than are inplementing distributed consensus algorithms and self-healing distributed databases.

I'd say that's quite more vague and doesn't quite sound like what an SRE is. You didn't answer my other questions btw.

Sorry, I meant "Site Operations Engineer". "Reliability" is an adjective assumed to every subject or role.