In my company, 80% coding for a senior SWE is rare. But if they deliver, management will give them some slack on the other evaluation axis. I have colleagues who work almost by themselves on new high impact projects. This has many benefits. No need to argue about designs, code reviews (people just approve blindly their code). The downside is that you need to deliver.
What also happens is regular developers (like me) want the same treatment as if they could end-to-end deliver "if they only let me", but many times can't, and actually need the structure and processes of a team. I've seen this freedom not working at all.
- an equalizer (entire team treated the same)
- a confidence booster (approval of others gives feeling of having done well)
- a way of distributing information (everyone is aware of all other team work)
You can run a team as a form of "competitive sport", and race everyone against each other; who churns out most "wins", and helpfulness, non-code-work, cross-team work are "distractors" to that objective hence undesirable and definitely not rewarded.
If the personalities in your team are "right" then this can work and by striving to best each other, all achieve highly. Have a single non-competitive person in there though... and it'll grate. Forcing a collaborative element into the work (whether by approval/review procedures, or by things like mentoring/coaching, or even just to force briefings to the team on project completion) creates a balance between the "lone crusaders" and the "power of the masses". Make the loners aware of, and contribute to, the concept of "team success", and give the "masses" insight into contributing factors of high individual performance.