Nah, this isn't a great idea. It's not that far off what most companies do anyway. I think most companies have a misunderstanding of what the problem is. The problem isn't that a particular piece of knowledge isn't distributed, it's that all the knowledge isn't distributed (because it resides with one person). You don't want to go crazy with duplicating knowledge amongst the team, you just want to split it up.

One hero is bad. Zero heroes is worse. You want lots of heroes.

Trying to create a structure where anyone can jump into anything at a moment's notice just leads to everyone having a superficial level of expertise in everything and no responsibility (or worse, responsibility that they can't possibly fulfill so they just get thrown under the bus if they don't hit impossible delivery targets).

All that does is move you from one hero to zero without waiting for your one hero to quit. It's resigning yourself to the bad outcome just to get it over and done with.

The tricky part is that the 'one hero' structure tends to form pretty naturally, so you have to actively take steps to prevent it. If you put a standard team in place and let it run wild, unless the devs understand this problem initially, then eventually you'll just end up with everyone deferring up the chain of command for both knowledge and responsibility over time until a few years down the track whoever was the technical lead on the project is now your hero.

I much prefer to have an ad-hoc structure where important work is divided up amongst the team and each team member takes total responsibility for their part. More senior staff shouldn't be trying to own more code and more responsibility, they should be providing more support to others.

EDIT: I don't think I actually explained how distributing responsibility solves the bus factor problem, whoops. The idea is that part of that responsibility is for managing the bus factor of your own work. This only works if the code you're responsible for is small enough that you can realistically bring another dev or two into the fold and get them ramped up properly with real understanding of the code.

People who work in finance are often required to take a two-week vacation every year. It's a good "bus" test and also a good way to find fraud.

I think this method talked about by another commenter here achieves a similar goal, but is more reasonable than chaos: https://news.ycombinator.com/item?id=30697309

You can get a good slice of this by encouraging people to actually use their vacation time.