1. The response object type isn't generic (as per project goals). In other frameworks, if I had branches returning different response types the types would conflict - no such issue here.
2. The cookie middleware is easy to use. In axum you had to return the cookie jar from your handler and trust the response tuple magic to do something with it to set the cookie in the response. I wasn't using tuples though, and due to the above it was non-obvious (and awkward) how to set the cookie in the response using response objects.
3. When you enable TLS via rustls it automatically makes non-default config changes to negotiate http2 (this is boilerplate in other frameworks).
4. Endpoint handlers are non-closures, and state must be shared via extensions/middleware (not captures). Rust closures are a hornet's nest so I'm plenty happy just being able to avoid them, but I also like that there's a single way to do things (and that way has good DX). In other frameworks you need to use async closures in order to get the compiler to intuit the future type since they're complex and you'd have to define it manually with a non-closure.
5. TLS configs are a stream to handle live cert refreshes.
It feels like a batteries included/one size fits all solution, but it's very well integrated and there are a lot of batteries. It's pretty locked down, where you can't easily tweak the internals. I haven't hit limitations from that yet, despite having some somewhat weird use cases.
There are also a lot of examples in the repo.
I was fighting with other frameworks for the last 3 days (a good 20+ hours), and when I hit another future-handler-generic-incompatibility error I threw my hands up and tried Poem, and got my code compiling in 30m.