This is not the same thing as 100% of your engineers being good, by any means, so it's not quite a stack ranking problem. In particular you can solve it by hiring good junior people, as long as you're not overstaffed (and if you are overstaffed, you need to find a way to figure out who to get rid of, other than getting rid of all the junior people).
Personally, I'm very suspicious of this theory. Whenever I've worked with a team that's all pretty senior, we work to automate away the boring stuff.
It might be necessary to let people do it to retain senior people and keep their morale up, and I've certainly seen companies be successful by letting good people overengineer things simply because it lets them attract good people and have them around when they're needed, so if that's your strategy, go for it. But you might be better off having a person with market salary $X spend a week doing something they don't yet find boring (and will learn from so that they can become senior) than having a person with market salary $2X spend three days automating and writing tests for their automation.
And there are a lot of interesting real-world problems (as in would-produce-business-value problems) that can't be automated, like gracefully remediating a legacy system where each user was able to get their own weird requirements supported. In the process of getting all the users onto a system you can automate, you need actual human time to work with each user and understand what they need out of your API surface, and while having senior people available is necessary for the complicated cases, it's unlikely to be necessary for all of them (and again, the ones that senior folks would find boring are good opportunities for junior folks to gain experience).
I don't think the short-term economic perspective really means much in the long term. Sure, if you spend $6x automating something a junior person can do for $5x, then your apparent extra cost is $x. But that's only true if a) the problem never comes up again, and b) no problem particularly like that one comes up again. Given the history of our field, that sounds like a poor bet to me.
Then you need to re-evaluate your definition of "Staff Engineer" at your company. Those titles are all relatively defined internally in the first place, just like junior/senior/staff/senior staff.
There is no industry-wide benchmark for those levels, so an internal curve is the only system that makes sense.
In the imaginary case where everyone in the company is a super high performer and everyone is equally as good, then it's not crazy to do away with those titles entirely as long as that's the case. But obviously that scenario won't last long as the company grows, and that's why titles/levels are gradually introduced.
They CAN all be top performers at their responsibility list...
For better or worse, Bloomberg does not have this. There are no formal levels or titles for ICs, despite having thousands of them. I thought it worked fairly well there.
If you actually have 100% of engineers operating at the Staff Engineer level, then it is what it is. However, the only case I can think of when that should ever be true is when you can count your developers on one hand. Once you grow any bigger, it's just not an efficient use of your money or the engineers' time to have that much experience concentration (as opposed to talent concentration, since more junior people can be talented too).