It is one thing if they don't talk. It is even worse if they have no experience but thousands of suggestions that don't work. And you have to debunk every of these suggestions to management while keeping the progress going.
Often, if the work horse leaves, no one is able to keep the project going or rewrite the project from scratch. They should be able to do the latter if their suggestions are so great and they have been kept back. But they cannot.
I've got a colleague with similar history - 24+ years of tech experience - software, hardware, networking, etc. He's built systems that processed tens of millions of dollars, has single-handedly reworked legacy crap spaghetti in to testable, documented, well-functioning stuff. He came in to a company, then covid hit, and no one else on the team has anywhere near his level of experience. One guy graduated high school 18 months ago and loves kotlin. Every meeting is him trashing everything saying how cool kotlin in. He's rewritten existing working image processing libraries from C (which my colleague wrote and were working in production) in to Kotlin because "kotlin is faster". Guess what's broken now?
They have multiple meetings per week where people argue about what encryption library they should use for JWT token signing. Like... 5 people - none of whom have ever written encryption, nor written a JWT, arguing based on all the blog posts they've collectively read. That's just one example. This happens constantly. And the manager is of the view that "everyone's opinion matters, everyone should be heard". So the person with decades of experience who's already written (and written docs and tests) for the system they're trying to migrate to has to sit and listen to people who can not spell SQL talk about how 'bad' his system is because it's not in Kotlin.
That feels like an extreme example, but the more I talk with other folks, it doesn't seem to be that uncommon. Probably 15% or so of folks I connect with seem to have wildly imbalanced skill levels in their teams which are not acknowledged as such. It's fine for someone to have less experience. It's not fine to pretend that your 6 months of CS-101 homework is equivalent to someone else's decades of experience and working/documented/tested code.
in my experience the team needs critical mass of decent developers. And by 'decent' I don't mean all-knowing experienced beasts. I mean adequate devs with ability to listen and to be wrong. If team has it, better devs naturally get listened more and everyone gets chance to improve from it.
It doesn't mean that you just don't let juniors express their opinions (everyone should be able to talk), but the 'weight' of dev's opinion determines by his track of previous cases. And obviously every opinion comes with responsibility for the result. If you forced your approach you need to be able to deal with the results.
Often, if the work horse leaves, no one is able to keep the project going or rewrite the project from scratch. They should be able to do the latter if their suggestions are so great and they have been kept back. But they cannot.