Long time C# dev and team lead here. Can't say I agree with you.
C# has become a great language for the "functional core, imperative shell" way of doing things. That means it has to be a hybrid language. F# is more tilted toward functional-land, C# is tilted toward imperative/OO-land. Both have their place.
If C# devs are constantly rewriting their code, that means there's no vision for that particular codebase. It's true that there are many different ways to "do C#." So, a developer or team needs to pick a particular way (OO classic, or functional core/imp shell, or functional, or minimal golang-style) and stick to it. It's more of an architectural challenge than you would get with a language that can only do one of those. The upside is, your system can blend approaches as necessary, all within one codebase. Every module of the system is perfectly suited to its task, from philosophy all the way down. Of course there's the danger of it becoming a mess, but the risk is worth the reward IMO. With great power comes great responsibility as they say.
What you describe can only be achieved in the short term at best.
If something can be written in 10 different ways then it will be re-writting in 10 different ways, because today you are leading your team and defining 1/10 ways. Tomorrow you leave and another lead or senior comes onboard and will disagree with your architecture and then slowly re-write everything.
Even worse, every time you add a new person on your team there's a 9/10 chance that they will disagree with your code. Your team will waste so much time between people just talking about how to write something because people get hung up on minor details instead of just trying to build a good application solving a real problem. The micro benefits of doing something in c# one way or another are in 99.999% of applications a complete waste of time.
Whenever I'm trying to hire C# developers (something I've been doing a lot over the years) I'm amazed how little people even know about C#. There's literally so much when you go deep that most people are completely clueless and it's getting worse and worse.
I've seen what you describe happen. But it doesn't have to be that way.
A wise lead may prefer a different path to their predecessor but respect the decisions that were made before them and realize that it's counterproductive to chaotically "drip-migrate." And good experienced developers will not get bogged down in endless debates with no clear winners.
It just sounds like you've had some bad experiences.
I've seen it happen too and it's not a C# problem. To attribute a social problem to a programming language seems odd.
A general rule is you made modifications to a codebase the same style / technology as the original codebase. I've seen bad developers not do this and it certainly turns into a mess.
C# has become a great language for the "functional core, imperative shell" way of doing things. That means it has to be a hybrid language. F# is more tilted toward functional-land, C# is tilted toward imperative/OO-land. Both have their place.
If C# devs are constantly rewriting their code, that means there's no vision for that particular codebase. It's true that there are many different ways to "do C#." So, a developer or team needs to pick a particular way (OO classic, or functional core/imp shell, or functional, or minimal golang-style) and stick to it. It's more of an architectural challenge than you would get with a language that can only do one of those. The upside is, your system can blend approaches as necessary, all within one codebase. Every module of the system is perfectly suited to its task, from philosophy all the way down. Of course there's the danger of it becoming a mess, but the risk is worth the reward IMO. With great power comes great responsibility as they say.