The momentary exposure in memory was the downfall of Lavabit. It is actually trivial to capture passwords submitted to servers during the momentary exposure. For example, when you login to a Drupal or Wordpress site over HTTPS, the POST gets submitted to a particular form - which is just a PHP file on the server, trivially editable. The password exists as one of the submitted form variables, which PHP then passes to bcrypt (or whatever).
PAKE only authenticates the password and generates a random session key. It doesn't enable the user to encrypt their data for a later session.
If you don't know what the PRNG is for, perhaps a cursory 30 second lookover and then crap all over wasn't enough. ;-) Watch the 9 minute Tech Video, which explains, the asymmetric key generator can't use a fixed length seed; it needs to be a random stream. Also, there's a challenge/response which can only be answered by knowledge of the client's private key, so your comment about the replay attack (I think you meant relay attack) is also incorrect - whichever you actually meant, you're wrong either way.
Password on an x509 cert requires the x509 cert to be stored or made available to the client somehow. The whole point of CBCrypt is to allow password authentication and encryption without the user needing to change any behavior or learn anything.
Take a closer look. The server has a copy of the client's public key on record before the authentication session begins. The server needs to authenticate the client. The server generates an ephemeral ECDH keypair. Now if an attacker manipulates the challenge or key sent to the client, the attacker has neither the server's private ephemeral key, nor the client's private key. So the attacker cannot provide a valid challenge response to the server. The worst the attacker might do is to generate a new ephemeral ECDH keypair and send that to the client instead of the keypair that the server generated - in which case the challenge response would be useless.
If you don't know what the PRNG (DRBG more appropriately) is for, you didn't watch the tech video. An asymmetric key generation algorithm can't work from a fixed length seed. You need to stretch the seed to an arbitrary length, because the asymmetric key generator requires a random stream.
Your 30-second look at the code needs more than 30 seconds. If a client connects to malicious server A, the private key it would use for that connection is different from the private key it would use on server B. So malicious server A cannot replay an authentication session on a different server.