OpenSSL is the part of the stack least likely to have an exploit.
I've had to write or be involved in writing 7 FreeBSD security advisories related to OpenSSL in the past six years. History indicates that OpenSSL is the most likely part of the stack to have a vulnerability.
And, being intimately familiar with what those advisories implied, I know how many of those had any impact on your system, and how many of them were well-addressed by FreeBSD jails. You're overstating your case, Colin.
My case wasn't that this would have protected me from past vulnerabilities in OpenSSL; my case was that OpenSSL is demonstrably crappy code. If code has a history of security vulnerabilities, odds are that it will have more in the future.
You make a fine case for not running OpenSSL at all, and a poor case for jailing OpenSSL. That would be nitpicking, except that you implicitly offer your strategy as advice for others.
It's funny that you're arguing this though, since, given your marketing message, I can understand making ineffective cost/security tradeoffs. I'm at some pains to say you're not crazy for doing it.
You make a fine case for not running OpenSSL at all, and a poor case for jailing OpenSSL.
Believe me, if there was a good alternative to OpenSSL, I'd be recommending it. Running OpenSSL in a jail is a horrible solution; but at least it's better than anything else.
That's ~1.16 advisories per year. Show me an operating system, web server, and web application platform (Java, RoR, PHP, whatever) that average less than ~1.16 per year each.
Further, out of all of the advisories for OpenSSL, how many would be mitigated using the technique from the article? Few or none, because most security issues in OpenSSL are about the way it implements the protocols (problems in the PRNG, problems parsing X.509, etc.).
OpenSSL is somewhat notorious for being a high-maintenance codebase. I personally think jailing it is overkill, but this argument (about whether the code is perfectly safe for a pre-auth attack surface) is a rathole.
Additionally, most interesting attacks on OpenSSL aren't done to root the system, but to subvert the level of authentication/privacy afforded by TLS.