Probably because the standard way of writing C# is too OOP-ish (for lack of a better term). Typescript lets you write just usual functions handling mostly typed objects, which is about as much abstraction as most people want (except for 1-2 classes for stuff like `BTree`), and as much typing as most people want.
It is because C# uses nominal types (C-like) and typescript uses structural types (ocalm-like).
https://en.wikipedia.org/wiki/Nominal_type_system
https://en.wikipedia.org/wiki/Structural_type_system
Although nominal types doesn't necessarily mean OOP-ish (inheritance-heavy) it is a pre-requisite (for inheritance-heavy code).
The distinction between the two is not a black/white thing but (modern) typescript (and Flow as well) is heavily focused on structural typing while C# is heavily focused on nominal typing. In fact the whole composition vs inheritance discussion fundamentally is about making types that behave in a more structural manner.
It's more likely they never tried C#, but have a very strong negative bias towards it nevertheless. C# can also be written very functional if you want, it's a multi-paradigm language like Typescript itself.
Of course it _can_ be. But that's not how major libraries are structured. Which defines how majority of business apps are structured. The way majority of folks use a language defines the language in its entirety, doesn't matter if theres a kitchen sink of alternative paradigms. You can't argue that C# isn't enterprisey in the majority case. In JS you can build on top of a whole, extremely popular library ecosystem purely using functions and options objects.