I’m not a fan of Django, in fact I’m more of a hater, I only pointed that this implementation is extremely limited. You say that you still have to craft the other components, but the reality is if a hook returns a Response and you give it as good, in the current request you don’t have to execute the rest of them, just return write this response out.
Look to another possibility, to middleware-free oldie tornado web, the option there is to define a prepare method called always before the actual handlers and a method finish that finishes the request and write a response (crafted in prepare). This could be an special component executed before and out of the rest or it can even be a normal function passed as argument to App, executed before all the chain of injected funcs.
I really would like to see a framework that does not enforce me to define an OPTIONS handler for each endpoint because it cannot handle properly flow control and otherwise raises MethodNotAllowed, and this is just a bleeding example, there are others.
Think of more serious use cases, a security hook, where you check x-headers for https or other important headers, and you want to cut the cord, but the reality is that if you raise an Exception it continues to run all on_response passing the exception, which can be dangerous, as you don’t want to follow up anymore and you don’t want all the components and all the hooks to be aware of these things.
This is why you encapsulate in a single hook and you put its on_request at the top of the list to be the first in execute and therefore to be the first to stop everything at this point, same as reverse-order on response phase, guess what, exactly the same behaviour as Django middleware.