I'm not sure what the original intent was, but the effective difference is that Errai looks up RPC services for every call, whereas plain message services are looked up once and reused.
For @ApplicationScoped beans this makes no difference, but for @Dependent beans this means that the plain services can still maintain internal state, whereas the RPC service instances will be different each time.
Hope that helps.
This does help, thanks. It's not immediately obvious to me why RPC classes should be different in this respect, any thoughts would be helpful. For now I will do the same in Spring, have singletons for MessageCallback and Services that use @Command, while supporting Spring's prototype scope which is similar to dependent for RPC.
I added a new post about a new spring errai github project from the results of looking into the CDI extension: github project for errai spring server side integration
I have basically just stuck to the same scope even though I don't yet know why it was implemented in this way. So plain services can be scoped as Singleton's in Spring, but RPC's can use other spring scopes, like prototype (dependent), session, request etc. So I'll just consider your answer as answer enough for now, thanks.