I don't know, but maybe these application servers are certified in some way so that they can be used in the right places that require certification (I'm guessing, not sarcastic)? Which would make sense, but some people host applications written in Spring on JavaEE application servers, which is like adding ketchup to a Greek salad.
For me, Java EE standardization makes absolutely no sense. You code to common programming interfaces when you need to break them down to use the underlying implementations.
Now I code in .Net and at least I don't have such dilemmas.
Nah, the old EJBs had a terrible programming interface. JavaEE 6 introduced a lot of good changes, but it was too late to convince people to switch back from Spring. To me it's like people abandoned JavaEE because it was hard to write fairly simple applications using EJBs (because it was) and switched to Spring, and then started writing large monoliths in Spring and realized they need to break them up into modules, so they invented microservices, but implemented them as standalone Spring Boot instances... when now it would be easier to go back to EJB + JMS. Microsoft has quite a similar "technology" called Microsoft Orleans, but it doesn't get much attention.
I would say that application servers with EJB and JMS are a good environment for implementing microservices. Everything uses less resources (memory) and communication is much more efficient, plus everything is written in Java, which makes it easier to maintain consistency.
As others have written, this work entails implementing asynchronous IO.
One system I worked with that was more heavily loaded than the usual intranet CRUD was an SMS lottery run by a radio station. They had "bonus rounds" that lasted a few minutes. When the host said "now send!" we were receiving a huge amount of data at the same time. However, it worked for years on Postgres 7.4 and regular hard drives :)
Have you read the entire thread you linked? People explained to Linus why direct IO is important to them. Besides, it's 20 years old and there were even no SSDs back then. The lack of direct IO in PG was one of (one of) the reasons why Uber moved to MySQL (https://www.uber.com/en-PL/blog/postgres-to-mysql-migration/, "The Buffer Pool" Section).
With buffered IO you will likely store a lot of the same data in memory twice- once in DB's memory and then in page cache. Now you can just give the memory used by page cache directly to DB, because it knows better what and when it needs.
I'm thinking lower resource usage (no double caching of data), shorter path to data so I would expect fewer bad things might happen during commit, and better performance in terms of transactions per second. Otherwise, I can't explain it any better than one of the lead developers himself:
https://www.postgresql.org/message-id/20210223100344.llw5an2...
The problem I had with getters in a fairly complex application (WYSIWYG editor) was handling mouse events, in particular onMouseMove - change detection was triggered on every such event, and the application was very slow.
EDIT: It was slow because there were many getters based on other getters etc and everything was recalculated on each event.
Even without Canvas HTML with SVG is great - you have lots of easy to add effects and built-in IO events. There is now a Web Animations API which is also easy and pleasant to use.
What I mean is that compared to, for example, WebSockets and WebTransport, WebRTC is more difficult to use (not through third-party libraries but "native" WebRTC data-channel API). But you are right and I was wrong, STUN is not necessary.
And were these application servers (like JavaEE) that bad? Separately deployed EJB modules can also be considered microservices, and everything was much easier to manage.