But that’s a problem with a specific framework, not C#. It’s true that some frameworks are quite hard to avoid using, but you could just as well create a lean vanilla project (which I gather the F# one was closer to), and you can choose not to use DI. I doubt F# would be all that much more expressive than C#, that you could not recreate whatever you did there.
From what I've experienced code based frameworks are often used because the language itself doesn't handle that case well on its own. In the case of F#, JS, etc, using DI again as an example, partial completion/currying once you get your head around it means that quite often programs are just chained one line factories (similar to the one line you used to register your singleton/instance in a DI framework so no more code bloat). As a bonus you learn something that is multi applicable, not just for DI and doesn't bring in any more "magic" or runtime errors if a registration is missing because the compiler catches it. Everything is just functions/modules which means mocking is a breeze too, refactoring is easier, etc.
This is my own personal experience here mentoring dev's in both technologies, especially when they come from different backgrounds. YMMV.
