Re: Many commonly used libraries [snip] also make heavy use of reflection
Meanwhile, in the real world, you often have arbitrary input to process, and it's often JSON.
You've broadly two options here - treat it as data and access it as such (like reading from a nested dictionary), or deserialise it into a strongly typed object.
Using strong types obviously leads to better structured code, as we're explicitly defining our domain rather than relying on a nebulous bucket of data, and better performance as we're using CLR data structures to hold our data, not big old dictionaries.
Deserialising does requires that you know something about the target type, so you can populate properties, validate values etc.
You could hand-craft a deserialiser, but frankly why bother when type introspection gives you reliable, testable and an above all predictable experience? Any decent code builds compiled expressions from the results of reflection rather than using it every call, as it is expensive to do, but the results when properly used (for example to build an expression tree which is then compiled to a lambda) give similar performance to hand written code.
And any decently architected software will allow selective optimisation where required, so your point about NEVER DOING THIS is somewhat naive and shows a lack of understanding.
Rather than banging on about '.not', perhaps you could instead use some of your evidently vast intellect to consider that some tools are best for some jobs, and every tool is a compromise between performance, effort and maintainability. Just a thought.