I see nothing wrong with a SLSB facade to provide a more course-grained API to the underlying business & data access logic. Think of this SLSB as a "business service" that is then bridged/proxied into the ESB via a custom action that you create (see quickstart business_service).
In theory you could handle all of the component to component dependencies via ESB custom actions. This would allow you an abstraction layer of the Message object which means you can inject transformations, mediation points, routing, wiretapping, etc into the "pipeline".
With that said, I'm a big proponent of letting the business logic of the application live where it lives today. If you have existing SLSBs, WSs, POJOs, etc, I wouldn't recommend ripping those apart to turn them into custom actions.
IMO, we don't have enough experience with ESBs in the market place to know what is the best practice in this situation.