These are straw man arguments, and you know it.
1) https://docs.microsoft.com/en-us/sql/t-sql/queries/select-or...
2) VBA is 1990s legacy, nobody in their right mind has used it for new software development in at least the last decade. VB.NET (which is semantically nearly the same as C#) has been around since 2005. I mean, that would be crazy! That would be like using a unsafe language from the 1970s like C for new software development in 2020. Nuts. Just nuts. Nobody in their...oh. Never mind.
3) ASP.NET Core MVC is very popular and very good. It's fast out-of-the-box, has native multithreading, native async without callback hell, has proper i18n support, etc, etc...
By the way, Blazor is absolutely amazing technology unique to ASP.NET, and at the moment only Rust has anything even vaguely comparable. But Rust has none of the back-end support.
ASP.NET also has impressive integration of technologies like reactive extensions and SignalR. I doubt there's a more elegant or easier-to-use API for WebSockets out there.
4) IIS works fine for www.microsoft.com, www.live.com, etc... Works fine for our customers. For an idea of how much more advanced IIS is than some other platforms, it is not only multi-threaded out of the box, it's NUMA aware too: https://docs.microsoft.com/en-us/iis/get-started/planning-yo...
Speaking of "shit shows", IIS, like most Windows server software, doesn't have to be restarted for a minor config change.
5) Enterprise-grade is software that is priced for a market that has requirements many developers haven't even considered.
Things like live backups that don't interrupt users. Error messages in French. Correct formatting of numbers and dates, because not everybody thinks that "month-day-year" makes sense. It means support for access control lists, not just "owner-group-other". It means centralised authentication support that works. It means auditing, not just "syslog". It means documentation written by technical writers, not a comment to "read the source".
PS: The first point is particularly bothersome, because database-side paging support actually makes very little sense from a relational theory point of view, which is why many engines never had support, or pay only lip service to it.
Let me explain: Sit down an think about what paging means in the context of a database with, say, 5000 concurrent user sessions. You either, A) allow users to hold on to transactions for nearly forever to ensure that your server is overloaded, or B) page through your data without long snapshots or transactions, in which case each page is stepping through different data because it's changing in between each page.
Now, lets say you get 5 rows out of 10, with values "0, 1, 2, 4, 5". What does it meant to get "the next page" minutes later? If you simply ask the database to "skip 5 rows and read the next 5", you could very well get back "-56, 2, 4, 7, 105" because god only knows what transactions have gone on since the first query. But if you say "get rows with values > max(previous result)" you might get "101,102,103,104,105" because so many rows have been inserted and deleted since then. Either way, the query has to be re-run, and neither query is guaranteed to return data that makes sense to a human user, or has valid relations to other data that was returned.
This kind of "feature request" is made by small-minded developers that have a) never read a text book, b) watched a production server processing $100M daily lock up, c) stayed up until 3am on Sunday fixing their mess. It's the kind of convenience feature that "works" until it either breaks everything in sight, or causes silent data loss or silent data corruption.
So please, before you tell me to get my head out of my ass, get some experience.