The SPON event SPON_playerConnected is not using onPlayerConnected at all. It is actually just when the local machine recognises a player object with a name that it hasn't seen before (read from large trigger). When it does that, Core updates the SPON_player_* arrays and then fires off the event. Thus, I can even use it in client-side addons or when a third-party script uses the onPlayerConnected handler, though it does mean that there can be a little delay before you are told about a new player (up to 15s when someone JIPs, though no delay at init).
You'll notice that it will always give you a living player object rather than just the name of the new player, so in most ways, it is more useful than the BIS onPlayerConnected (e.g. I generally use it to add event handlers), unless you really need the player ID. There are also SPON_manFound and SPON_vehicleFound events that do the same sort of thing. In the mission-script version, these are a way to have object init code run, albeit not immediately on object creation (in an addon, of course, you could use XEH for this)...
I will be incorporating XEH init handlers in the addon version soon, to avoid the delay on player JIP or script-based soldier/vehicle creation. The mission-script version will continue to be delayed, of course, but as far as a 3rd party script is concerned, the two versions are interchangeable.
(Ironically, I originally planned to hook up with onPlayerConnected for this event, but I was using object inits for broadcasting SPON events and I couldn't work out why they were crashing my game all the time; it was actually recursive use of vehicleInits, but I just couldn't work it out at the time. Now, however, with the advantage that I can use these SPON events in client-side addons, give an object reference and avoid a bit of bandwidth usage, I can't see a reason to go back to using onPlayerConnected with all the compatibility issues that would bring me; I already have enough problems with the SPON Core key event handlers being corrupted by other scripts using the single-callback-only 46-onKey handlers!).