A big thing is that you may be using HTTP/2 or HTTP/3 already if you use something that terminates HTTP for you. This doesn't have to be Cloudflare or whatever; if you run Nginx in front of your Rails server, you can just have Nginx handle HTTP/2 for you. Many deployments or services like AWS, Heroku, S3, etc already enable HTTP/2 for you and it's transparent on the client end.

The widespread deployment of caching utilities and other frontend application middleware was, in a paradoxical way, a huge boon that lead to easy success for HTTP/2 (and now /3) while making it appear a bit bland to everyone else. "Nobody uses this, right? I mean, I've never changed anything." You weren't supposed to! For many purposes this is intended: service providers, operational admins etc can largely tweak this all independently at the caching service layer, for instance. Taken together it's mostly just "free performance" for the case of a user who has a reasonably reliable network.

Now, don't get me wrong, you need to understand caching and the HTTP connection lifecycle. There are aspects of newer HTTP versions that do impact the development experience. For example if you're sure you're using HTTP/2, you can rely on multiplexing. That means that, for instance, if your user has a dashboard with many panels, and each panel is doing independent requests to get metrics data (like Grafana, for instance), then all of those HTTP requests for data happen over 1 TCP connection. If you had to use many connections, you'd either have to throttle/serialize updates, use pipelining, or it might not work at all since the browser will refuse to open too many at once. But you can rely on this working with HTTP/2. If you rely on multiplexing, the penalty of having many small files on a single domain is much smaller. So those user avatars hosted on mybusiness-static-content.net will load much faster for all users too. That's just free performance on the table. But you have to design with it in mind.

So to answer your question: why should you migrate? Well, in general the answer is simple: better performance and better security (HTTP/2 and HTTP/3 both mandate TLS, for example), and HTTP/3 handles flaky mobile connections much better than either v1 or v2. That might really help for something like an API endpoint that mobile device clients access, for instance.

If you start a new project, should you consider anything except HTTP/1.1? Yes! Because HTTP/2 and HTTP/3 are here to stay, so it's not like you're betting the farm on something untested. You do need to consider client library availability; you can't get away with a half-baked "HTTP/2" implementation as easily as you could with HTTP/1.1 (this is the dark side of people who complain about binary-vs-text formats: it was very easy to get HTTP/1.1 very wrong). But they have tangible benefits for end users, and, taken into consideration, can help you do some stuff you couldn't before. Ignoring any claims it's a sign of website bloat, "download a lot of small files" is actually a legitimate, huge use case you couldn't do efficiently before in the browser or otherwise! Some non-browser workloads I've had see incredible performance improvement just from this alone. And if you're writing server software? Well, a good reason is "because it's easy to deploy". You might only need to change a configuration in your existing terminator.

Will there be an HTTP/4? I guess nothing is impossible here but I wouldn't bet on it. HTTP/2 was the big change. HTTP/3 was a "big" change not for HTTP, but because fixing HOL blocking at the TCP layer can only be done by, well, not using TCP! It's otherwise the exact same thing you know already, just in binary form, over a different transport stream. There could of course be other things down the line, but it seems like if anything continues to evolve, it will be QUIC itself, and less-so for HTTP.