I just did look at this "feature" and I can see this "unwrapping" is done for two different reasons:
a) to be able to mark the request/response internal state as being included/forwarded for which the Portlet API requires different handling
b) to be able to do the actual servlet dispatch using the ServletRequestDispatcher which only can take a ServletRequest & ServletResponse as parameters
I think it's not difficult to come up with a solution for a) by using only temporarily "unwrapping" just to mark the internal state.
Note though, this then will leave the door open for actual wrappers to "break" the Portlet API requirements when overriding some of the specific methods "incorrectly".
But, the second reason b) really is a killer: how would you do the actual servlet dispatch which requires the underlying ServletRequest/ServletResponse without unwrapping?
Maybe wrapping the (possibly itself wrapped) PortletRequest/PortletResponse with yet another HttpServletRequestWrapper/HttpServletResponseWrapper and delegate all their methods back to the PortletRequest/PortletResponse?
I'm not sure that's 100% guaranteed to work on all (or at least some) web containers which, like Tomcat, sometimes do their own "unwrapping" to get to their own internal state...
And what should be returned for the following method then: ServletRequest HttpServletRequestWrapper.getRequest()?
I'm willing to try to solve this one, but right now I don't see a "solid" solution yet. But if you have any ideas what might work (without resorting to webcontainer/vendor specific solutions) I'm all ears!