Stratus doesn't know anything about "user IDs". those are purely constructs of your application. all Stratus knows about is a client's peerID, which is unforgeable (by which we mean it's computationally infeasible to appear to Stratus or another Flash Player with the existing peerID of any other peer). and a peerID only has meaning for the lifetime of your NetConnection to an RTMFP server (such as Stratus); they cease to exist as soon as you disconnect and can't be recovered or re-used.
the VideoPhoneLabs and reg.cgi examples are intended to be illustrative of the underlying concepts of P2P communication and mapping application-defined users to peerIDs. they are explicitly not secure at the "user ID" level.
i'm not sure what you mean by Stratus "not validat[ing] the ... developer key provided from the client" though. Stratus *does* validate it, in the sense that the provided developer key must be *a* legitimate key issued by Adobe.
RTMFP provides some interesting low-level hooks upon which you can build several kinds of sophisticated security. as i mentioned, the peerID of a Flash Player is unforgeable. you could register and look them up using a trusted and secure source (HTTPS and application-level username/password). you can use the secure session nonces (exposed in NetStream.nearNonce and NetStream.farNonce), which are unguessable, unforgeable, can't be observed by a passive third party, and which can't be intercepted without changing them, along with local shared objects and a cryptographic hash function, to build an SSH-like identity continuity system which, while not initially authenticating a user, can be used to prove that "next time" you're talking to the same person as last time.