That’s a valid point, but there are also plain Flow applications that will build up the whole Response inside the single action. It would be bad to force them to shift such decisions to a http component, where they need to build one big huge switch statement to change headers based on the controller+action combination.
Maybe we have an architectural issue here, that we handle both cases exactly the same? What if we had a generic ActionResponse that just renders content and a lower level MvcResponse that enriches the generic one with header and cookies? That would probably make the API more complicated and lead to weird if ($this->response instanceof MvcResponse) { checks inside actions.
Using an exception to control the flow was probably not the best idea, but the current MVC architecture builds upon the fact of having a mutable Request and Response object that can’t be replaced
Sorry, I think I don’t follow 
What does the mutablity of Request/Response have to do with throwing exceptions to redirect/forward?
Changing this might be a project worth thinking about, but I’m not sure if we should make the (breaking) change any bigger!?
Yes. We could go both ways to keep things b/c for now and see how it works out first. An action could then either throw an exception as before or return an object to get the same result of redirect/forward.
Therefore probably people will reach the limits of the API (until it is extended to serve all common use cases) and will want to do nasty things directly from the action.
I’m unsure there are so many nasty things you can do with the response alone. Status, body, headers (and cookies and/or cache-control as a special/convenience setter for a specific header).
Maybe to make that clear: I consider the API of the Mvc stack to be Controller::action(ActionRequest): ActionResponse - of course not literally, but conceptually. So theoretically, the ActionRequest could be immutable and the ActionResponse be a very shallow mutable API to alter the actual HttpResponse outside the Mvc dispatch. It could even contain a couple of the API methods we deprecated in HttpResponse, like appendContent TASK: Deprecating non PSR-7 methods by kitsunet · Pull Request #1366 · neos/flow-development-collection · GitHub
With the mutable HTTP request/response they could do (cover your eyes): [ugly code] That’s no longer possible.
And that is a good thing 
If you want to interact with the http response directly and alter it, create a http component/middleware.
But where do you read that the dispatch component should be the final handler?
Following PSR-15 Meta Document - PHP-FIG
The innermost middleware is the one that either creates the PSR-7 response, or delegates to last resort RequestHandler that can create a fallback response (i.e. NotFoundResponse or a RedirectResponse to a default page)