Methods in C# are non-virtual by default and almost every class in the core libraries is sealed and the world hasn't ended in .NET land.
I have definitely done some hacks to work around bugs in frameworks I've used. But I've also had to deal with users who broke my libraries or inadvertently wandered into the weeds because it wasn't clear what things were and weren't allowed.
This is one of those features where the appeal depends entirely on which role you imagine yourself in in scenarios where the feature comes into play.
And I have heard people say that the "sealed" class in the framework is often mistake, as they have experienced pretty much the limitations described here. In other words, Curt Clifton's theory has a lot of merit in practice.
But .NET definitely struggled with cultural issues around making APIs virtual. Because of Microsoft's strong 'no breaking changes' rule they were extremely cautious about adding virtuals- in my experience it was not unusual to see it costed at 1 week dev/test time for a single virtual on an existing method (in WPF).
C++ is also non-virtual by default and I think it's worked out OK.
Some of the cultural issues around avoiding virtual came from hard lessons with v1.0. After shipping v1 they realized that there were a large set of security and compatibility issues with not having framework classes sealed. No-one I worked with really like the idea of sealing all our classes, but the alternative was an insane amount of work. It is just too hard to hide implementation details from subclasses. If you don't hide the details then you can never change the implementation.
I can't say for swift, but there were also real security challenges. It is hard enough to build a secure library, but to also have to guard against malicious subclasses is enough to make even the most customer friendly dev run screaming. My team hit this and it cost us a huge amount of extra work that meant fewer features. vNext we shipped sealed classes and more features and the customers were happier.
I have definitely done some hacks to work around bugs in frameworks I've used. But I've also had to deal with users who broke my libraries or inadvertently wandered into the weeds because it wasn't clear what things were and weren't allowed.
This is one of those features where the appeal depends entirely on which role you imagine yourself in in scenarios where the feature comes into play.