In one line, I would say – “Long Term Maintainability”.
As developers we work in teams of every size, which work together but on different parts at a time. When working in teams following is desirable:
• We should be able to consume components created by others and vice-versa.
• Someone should be able to manage my code ,if say, I switch the company.
It’s not impossible but substantially hard to achieve those objectives with a language that don’t adheres to OOPs. And when I say that, I rule out Node.js and PHP as Object Oriented languages. They are “Object Capable Language”.
As for PHP it always had backward compatibility issues. They are infamous for making breaking changes. And for Node.js, even with transpilers it lacks essential features like interfaces, abstract classes etc.
When you work with OOPs based language you necessarily impose a kind of contract in the components that you create. And those who consume your components have to obey that contract. That really cut-down half of the unwanted surprises that comes with non-object oriented language, while consuming services written by you team mate. And luckily, C# is based on OOPs.