I agree with you guys, but from what I've read, business logic (or god forbid persistence logic) has no place in a GUI command in the first place. It reminds me of VB6 programming where the click of a button would directly save stuff in the database. I hope none of you guys still write 1 or 2 tiered applications... If you have a decently decoupled architecture, the only things your GUI commands will contain are service calls and GUI specific behavior, and if that's the case, I don't really see the need for another abstraction or UI decoupling.
When creating a 3 tiered server-client application (which most Swing apps in enterprises are), most logic should be executed on the server side, and if logic needs to be done on the client side, it should be through a service call or some sort of UI-decoupled command class, providing the necessary abstraction in the UI command and the reuse you're looking for.
Spring RCP is pluggable towards its commands through the existence of wrapppers. For example, there's an RCP wrapper for Swing's Action class. It would be really easy to create a wrapper class for Apache's Command class, feel free to contribute.
The heart of the case is: there are a lot of UI decoupled command frameworks out there. At the moment, its a whole lot easier to provide wrappers for those frameworks instead of inventing yet another command framework (DRY). Spring RCP is a GUI framework, and it's commands are UI coupled, which is quite logical.
MSN: PM me please
Spring Rich Client Project Lead