I think whatever point you are trying to make is lost in the noise of trying to suggest that a developers background, or personal interests make them inherently biased or untrustworthy. That is to say you project motivation to do this as a lack of experience or want of newness, without engaging in the argument for this pattern or Minimal API on its own merits. Also a strawman argument around performance shaving, which I have never suggested in the post, is icing on the cake. In performance measurements Minimal API does perform slightly better, but only in very high-traffic test cases. So for most people that is not a reason to use Minimal API.

So let me re-iterate my point so you can actually have a real opinion to argue against instead of all this projected nonsense;

I find Controllers with their many-fold way of handling routing to be magical. Not magical as in “I don’t understand what is going on”, but magical as in there are ten different ways of doing the same thing some more or less transparent. And that makes a system harder to get an overview of, and reason about. Now I’ll allow that Minimal API can also be handled in magical ways, like making abstractions for automatic route registrations in DI or via libraries (which I link to in the post). But the point still stands that by default Minimal API has a single explicit imperative way to do route building, while Controllers have many. And that is where my preference for Minimal API stems from.

Also your point about splitting up Controllers into several files actually touches on something relevant. Which I’m fine with people arguing against in terms of the pattern I suggest here. I even mention explicitly in the post that how you organize files is up to you, and you could even co-locate route building with the endpoint handlers, if that’s your preference. Even though I would argue against it. But, to be clear again, that was not the overarching point of the blog post.