Note that you are not forced to use user BWREMOTE for BW. It is just an example and in the customizing you can propose the user name, but the destination is independent of that.
The destination must work and be authorized of course, regardless of which user is really enetered into it.
RFC destinations are system level connectivity in most cases and many applications using RFC will work better if the logical system name is the same as the destination name, but you are not forced to use it. You can also map the logical system name to a different technical RFC destination name if you want to or if the system connection scenarios are incompatible with each other.
For example... the one connection does not support the RFC login screen so you must use a fixed user in the connection, but an application requests trusted RFC for the connection with the current user. In this case you can split them.
Another example (for SOLMAN) is that one connection wants to perform simple monitoring of the target, but another wants to be able to navigate to it with SAPGui interaction and yet a third one is for the CUA. In this case you will have at least 3 connections as you dont want to mix the functionality and application authorizations in the target. On thhe client side you can then optionally use authorization object S_ICF to create "security zones" for the outbound destinations once you have split them,
But you should however try to keep the number of connection types to a minimum as you have to "house keep" them, so only split them if there is a functional or security requirement to split the user context for the call to the backend.
Cheers,
Julius
ps: you should use users of type SYSTEM and not COMMUNICATION!