The problem with this approach is that you need to sit with the response in memory while you undo the stack. If you have a pipeline with 10 plugs, it is most likely that only one or two need to modify the response. In Plug you would register callbacks when you need it. In the Rack model, you need to hold all 10 middleware in the stack.
I would also argue that the use of Plug is simpler for the majority of cases. You can’t get simpler than a single function that receives the connection and returns the connection. As an example, in Phoenix you can use plugs both as “callbacks” in your controller and in your pipelines. However, in Ruby, almost all frameworks and libraries, such as Rails and Sinatra, end-up introducing a new lightweight abstraction that resembles Plug, such as callbacks or filters at the controller and application level.
However, I definitely agree the Plug model is more complex than the Rack model in the scenarios you mentioned. Part of the problem here, especially in regards to exception handling, was that the issue was discovered as we moved forward due to the interplay between Plug and immutability. I believe it would be less confusing if those issues could have been articulated up front.
That’s not saying Plug is the ideal interface for everything but for HTTP the list of pros fairly outweigh the cons (IMO 
), especially with HTTP 2 being available and playing even more on the strengths of streaming, data push, multiple responses, etc.
