Does (Ethereum) blockchain handle request truly asynchronously?

So, if we send 100 simultaneous requests to a web server, there would be 100 threads spawn to serve these 100 requests. That's what I'd call asynchronous handling.

Now, 100 transactions are created simultaneously on the Ethereum (or any similar blockchains), how would they be handled. Assume these 100 transactions are initiated by 100 different accounts and the requests are received by different RPC Nodes. Here are what I understand:

Some transactions with higher gas set will have higher priority. Still, in the end, they will have to be in a queue?

Now, one transaction with highest priority is selected, it will be broadcasted to the network (of all miners?) and the race begins. The most powerful node gets to create the block. Or few transactions (say, 10), I don't know, as as to fill up the 1MB limit of one block. In the meantime, what happens to incoming transactions, are they continued to be received and queue up with the other 90 transactions?

That being said, except for the winner node, all the other nodes actually do not help creating the block (they do help validate it though). Is that correct? So the transactions are in fact processed synchronously. Which makes blockchain far from a real distributed system (a distributed database, maybe). Aside from PoW, is it the main reason Ethereum is stuck at roughly 25 TPS?

Some newer blockchains like NEAR may help to improve TPS (100k?) by divide the network into shards and PoS. That does help. But each shard is fundamentally a small chain and still handle transactions in a synchronous manner. If, for some odd reasons, all the accounts initiating lots of simultaneous transactions reside in the same shard, would that cause the same trouble. And if a transaction is not just changing account balance, but performing some tougher calculation, wouldn't it be much worse?

Please correct me if my understanding goes wrong. Thanks.