Wouldn´t that defy the whole point of being able to catch the thrown exceptions from the invoking code? You're right however that this only works in case the remote service throws a ServiceException, which isn't even the case always. I haven't tested it for all transports, but at least for JMS I can say that exceptions aren't returned at all to the caller, they are send to the default exception handler (which discards them into the log). For the VM-transport this works (as it is thrown form the same thread).
For my project we resorted to using a custom exception handler which would use the reply-to property of JMS to send the exception back to the caller. However that solution feels kinda hack-isch.
Anyway, I think we're dealing with two different scenarios when implementing the final solution: (1) we're just trying to bind an endpoint (e.g SMTP) to easily send data to that endpoint from Java code (e.g. a MailMessage to send an email) and (2) we're binding a remote component where Mule handles the actual transport that is used for communication (e.g. JMS, RMI, SOAP/HTTP, etc), a bit like SCA. The patch is meant for option 2 off course, can't really tell if it interferes with option 1 though.
Another issue with remote invocation (option 2) are RuntimeExceptions. We cannot send those back to the service as this may result in ClassNotFoundEx (e.g. one the called component uses Hibernate while the calling component doesn't). In my custom exception handler I would just send back a plain RuntimeException with the original stacktrace as message (based on the assumption that the invoking code can't do anything with any RE send back from the callee).