As you say, the documentation is lite. I like the way you said you have to think like an Insteon Device. Of course that requires you have the underlying Insteon knowledge. Only a Controller can control a Group so for the EZSrve to control a Group/Scene it must be defined as a Controller of the Group/Scene. Makes sense when you think like an Inston device.
I think you do need to assign a unique Unit (Group) number to each scene for two reasons. First, thinking like an Insteon device, when a Group Broadcast message is issued, it only has the controller device address and the group number, so for responders to begin to react to a Group Broadcast message (for performance reasons only) it must match the controller device address and group number when it looks through the link database. Of course the following Group Cleanup Direct message does have both the From and To Insteon addresses but the group number provides the number that must match the responder link record containing the device characteristics (bright, ramp rate) for the group. As a Keypadlinc can have the same responder in different Groups (buttons) where the Group (button) number identifies the specific group, EZSrve must use unique Group/Scene numbers for it to work correctly as a multi-unit controller, just like a Keypadlinc does for its multiple buttons. Except in this case, EZSrve is not limited to 8 buttons (groups).
Second, I have seen that macros store only the Group number (not the scene/group name) when a Scene/Group is the object of the Then clause of a macro. That suggests the developer was assuming each scene for which EZSrve would be a controller would have a unique Unit (group) number.
EDIT: Timers also store the Group number of the scene rather than the scene name itself. Just more confirmation that the Group (Unit) number must be managed correctly. I just tried a Timer controlling a scene which worked and the timer entry in the XML has the Unit (Group) number. Caution here because I created two scenes with the same Unit (Group) number (on purpose to see if EZSrve would allow it) with different names of course. The timer that turns on the first scene also turns on the second scene because both scenes have the same Scene/Group number. At some point EZSrve should insure that scenes with EZSrve as the controller do not get assigned the same Scene/Group number.
As for adding EZSrve as a responder, thinking like an Insteon device, it is not technically necessary for a controller of a group to also have a responder link but if you want the controller to stay in sync with the status of the responders in the group then the controller also needs a responder link. Of course if the responder(s) in the group are responder only devices (like a Lamplinc which cannot function as a controller even when local control, load sensing, turns on the load) then you would not want a responder link for EZSrve. On the other hand, if the responder(s) in the group are Switchlincs, where you can also control the load with the paddle, then you would want EZSrve to also be a responder so it would know that the load was turned on/off by the paddle.
Reminds me of the movie “Contact” where some guy says “if you think like a Vagin, in multiple dimensions”; until EZSrve documents all aspects of the Insteon architecture as it applies to EZSrve, it really does help to think like an Insteon device. I do like your analogy.