in subtype polymorphism it is easy to add a new implementation (just a new class implementing a given interface), but it is hard to add a new method (you need to implement it everywhere and with bad design those methods may not make sense at all for all implementations)

In those cases you use a base class, not an interface. This is the reason why there is an abstract System.IO.Stream class. Very seldom do all properties make sense for all types of streams, so the base class implements them in a defensife manner, and you can override those you need. This also means adding a new method to a base class doesn't necessitates updating every implementation of it unless you mark the method as abstract. C# even allows you to provide default implementations in interface now (which I personally think is super ugly), which solves the limit of only being able to derive from at most one base class.

In contrast an Union type of each type of piece (King, Queen etc) it is much easier as union type better represent the real world than class design. With that Union type you can just add switch cases in multiple places

And that exactly is ugly. If you add a new type to your union you have to check every single function that touches this type to make sure it handles the new type. Static analysis can't do that for you because the static analyzer will never know whether you are purposefully not intending to handle the new type, or if it was by accident. Best you can do is to make your implementation throw exceptions on unknown types, but this turned something that should be a static code analysis task into a runtime error. Using OOP derivation practices forces me to implement new types in the appropriate locations. You listed 5 possible components where you need this switch statement, and I guarantee you, you will not only need this once per component, you need it to some extent in every function that handles pieces. Chess has 6 distict piece types, and by needing more switch statements than there are pieces you create unnecessary work for you and technical debt for the next person. It would be better to offload the implementation to the pieces instead. If I'm somehow worried that updating an interface forces me to provide an implementation to countless derivatives, I can make them derive from a base class that implements the basic functions (like IsPathObstructed) instead. Then I have to implement it exactly once, and all pieces can use it. The knight doesn't needs it, so I simply don't call that function inside from GetPossibleMoves, or I can override the implementation with a hardcoded "false", depending on what pattern I prefer.

This is probably why these things don't exist in C#, but are present in F#.

Also pretty much everything they suggest in the documentation is accompanied by the equivalent C# code you would need to write now. In other words, we don't need to add this to the language at all, we can just put it into a nuget package with a source code generator.