There are only two technical reasons to require asynchronous requests, and neither of them applies to a game like Travian because real-time updates are not required.
- You need to make instant updates to the client, so you need to initiate communication from the server. Before websockets, this could be accomplished with long-polling (keeping a request open long after it was initiated), and submitting additional response content as soon as it became available.
- You need to answer or receive requests that take a long time because of total size and bandwidth, but still need to accept and work on new requests during that time.
These reason don't apply to Travian-likes because:
- You don't need instant updates. Timed resources can tick continuously on the client-side, but the server always should validate them based on
previous_value + rate * elapsed_time. That update can happen whenever a user refreshes their page or attempts an action; no real-time push is required. Even if you need regular updates, they can occur through a simple polling mechanism (without keeping connections open).
- Your requests should not (and can not) be that large. This requirement would cripple any game server with a large number of users. Even Youtube delivers video via so-called "pseudo-streaming", delivering only the bit of content you need when you need it, which can be accomplished with separate requests to the server.
If you believe you can get away with RESTful or any other stateless communication (and indeed you can), then you do not require an asynchronous server architecture. You should select a server based on its ability to process the game state quickly, and possibly the ease of increasing that capacity on-demand. Concurrent connection count is mostly irrelevant.
It sounds like you are falling for the term "asynchronous" as a buzzword. I call it a buzzword because non-blocking requests have no benefit on a server that is busy doing work to answer the requests. Asynchronous requests only offer one "advantage", which is to allow the dog-piling of more incoming requests (that still take unacceptably long to receive a response). The single reason to require asychronous requests is if you expect your requests to take a long time to complete.
Asynchronous server systems increase the maximum number of concurrent connections. That is completely irrelevant if you prefer to use stateless (RESTful) requests. For example, the largest number of twitter posts per second, EVER, was about 6000. Will your game community need to make more requests per second than that? Some quick math will allow you to disprove that notion. Half that rate would be 260 million requests per day.