Flask vs bare Werkzeug

I'm building a new web application from the ground-up, however, I have a few requirements/preferences that seem unusual for the python web-app world:

• I only need to build a REST api. There won't be any static file storage (we're using s3), and I don't need template rendering
• I want to use RAML (or jsonschema) for specifying valid input/output data for my endpoints.
• Our domain model requires a sort of hybrid CRUD/CQRS setup. I'm not really honoring either, but we're basically enforcing the CQRS paradigm with Actions, and generating CRUD changes on our stored objects (what would be Projections in an Event Sourcing architecture), and storing Events as a secondary concern, if they're relevant. I really doubt there's anything out there that'll help with this.
• We're on AWS, so we're using DynamoDB as a backend, which doesn't seem to be supported very often.
• We don't need Swagger, or HATEOAS, or JSON-API, since this is going to start out as an internal API. I want to use jsonschema/RAML in part so that we can bolt that stuff on later easily.
• Our API will always accept JSON and return JSON. The less stuff going into request body stuff the better; I've always hated fighting with magic content negotiation stuff.

From what I can see, Werkzeug on its own is a better fit for us than Flask. It seems to have everything we need from a web framework, and with fewer opinions about how an app should be structured. I've used Django in the past for a non-trivial application, and my least favorite thing is fighting my framework.

Also, as a sidenote, I really like Ring in Clojure. It's a wonderful, simple, pluggable, low-level api, and it seems like Werkzeug is the equivalent.

Here are a few points of comparison I've considered:

• Logging is easy in either - both just rely on python.logging
• Redirects and errors are super easy. But they can quickly become opaque with frameworks, since they're a secondary concern. I'd rather write my own code there.
• Testing is easy in either - Flask has some utilities, but in my opinion, it seems more straightforward to just pass info to a uwsgi handler and check the output.
• The concurrency model via thread locals (request, g) in Flask seems great. But I'm not sure it's necessary if you don't want global access to those objects? I feel like I'd rather just pass the request context in to whatever needs it.
• I don't need templating, signals, static files, configuration management helpers, flashing, or class-based views. This all looks to me like bloat for our use case, and makes me nervous that Flask is going to be pushing me into server-render oriented design patterns, while Werkzeug won't bother me there.
• Routing seems just as good in Werkzeug as in Flask. Minus the decorators, but I don't actually want to go that route anyway.
• I'm not sure what, if any, extra magic Flask does for content negotiation. I'd really like as simple an interface as possible for retrieving data from requests, either in the form of a JSON string/stream, or a python data structure. (File uploads are tricky, but something like Django's FILES would be fine)

Am I missing anything substantial?