It sounds like you are conflating the strength of SSL and the strength of encryption. The two are distinct; SSL is a protocol that uses encryption, but the security of SSL is not strictly dependent on encryption. SSL can be vulnerable even when the underlying encryption is not.
Overall, security and speed for SSL are not a tit-for-tat trade-off. Making SSL faster can have nothing to do with the actual encryption because SSL is a somewhat bulky protocol layer on top of normal communication streams. The "fast" part of SSL is actually the raw encryption, since encryption algorithms are well-studied for speed of implementation and many high-end servers have hardware support for doing the encryption. The slow part of SSL is everything else.
If you read through the link you posted, you'll note that a lot of the speed issues they're addressing have to do with the overhead that the SSL protocol introduces. They're trying to minimize the number of round-trip TCP exchanges, trying to minimize the data that needs to be sent to start a session, trying to cache keys to avoid re-creating them for returning clients, and so forth. In theory, these these might be doable with no impact on security. (But each tweak must be evaluated on a case-by-case basis.)
Speed and security do have something of a natural trade-off. Any tweak to SSL to make it faster needs to be scrutinized to ensure it doesn't add a security vulnerability. But it isn't just a law of returns, where faster equals less secure and slower equals more secure.