This question is timely for me - I was writing almost exactly such code yesterday. Just replace "Animal" with whatever is relevant in my project, though I'll stick with "Animal" for the sake of discussion here. Instead of a 'switch' statement, I had a somewhat more complex series of 'if' statements, involving more than just comparing one variable to certain fixed values. But that's a detail. A static factory method seemed like a neat way to design things, as the design emerged from refactoring earlier quick-and-dirty messes of code.
I rejected this design on the grounds of the base class having knowledge of the derived class. If classes LandAnimal and SeaAnimal are small, neat, and easy, they can be in the same source file. But I have large messy methods for reading text files not conforming to any officially defined standards - I want my LandAnimal class in its own source file.
That leads to circular file dependency - LandAnimal is derived from Animal, but Animal needs to already know that LandAnimal, SeaAnimal and fifteen other classes exist. I pulled the factory method out, put it into its own file (in my main application, not my Animals library) Having a static factory method seemed cute and clever, but I realized that it didn't actually solve any design problem.
I have no idea how this relates to idiomatic C#, since I switch languages a lot, I usually ignore idioms and conventions peculiar to languages and dev stacks outside my usual work. If anything my C# might look "pythonic" if that's meaningful. I aim for general clarity.
Also, I don't know if there'd an advantage to using the static factory method in the case of small, simple classes unlikely to be extended in future work - having it all in one source file might be nice in some cases.