More importantly, the working group appears to be geared towards saying "yes" to new features, when exactly the opposite posture is needed. The Heartbeat feature is just the most obvious example, because its reference implementation was so slapdash.
The weirder thing here is that it would even be controversial or newsworthy to disable TCP TLS heartbeats, a feature nobody needs or really ever asked for. Why was it enabled by default in the first place? What sense did that decision ever make?
As far as I can tell, there was only one person that raised the "we don't need this" objection (Nikos Mavrogiannopoulos, GnuTLS principal author). He asked for a defense of the feature on three occasions  , and received a response twice, both responses from the same person. There was no further discussion, so either his objection was addressed or he felt further discussion would be unproductive. I would be interested to know which. GnuTLS does ship with heartbeat disabled, so it's possible Nikos continued to express skepticism about the feature.
However this document was eyeballed by many security experts, who I will not name and shame here, who proofread or made comments or edits to the document, without objecting to the general premise.
It seems to me that, inherent in the nature of a working group, the specific parties who are in favor of the feature will always be better represented than the interests of a wider audience that faces the nonspecific harm that the feature might be implemented poorly and introduce a security vulnerability. Sort of a reverse-NIMBY situation if you like. The software community cannot mobilize to combat every new TLS proposal on the grounds of nonspecific harm, but everybody with a pet feature can mobilize to make sure it is standardized.
You're essentially asking the same exact question Theo de Raadt is asking, hence his extreme suspicion of IETF.
Why write a call to setsocketopt() when we can just reinvent new features?
Those parameters describe no connection made by browsers.
In other words: application-layer keepalives are only valuable to applications that already have the freedom to define their own truly application-layer keepalive anyways.
[edit: actually I was under the impression that the payload addressed response order concerns in UDP.]
In the hierarchy of sensible TLS decisions, you have, from most to least reasonable:
1. Not adding new heartbeat extensions to DTLS or TLS.
2. Adding new heartbeat extensions to DTLS only.
3. Adding the same new heartbeat extensions to DTLS and TLS.
4. Adding two different new heartbeat extensions, one for DTLS and the other TLS.
The penalty for security fails of useless features should be a slow, painful, humiliating death.
I've not read as much as I would like on the IETF's involvement in this but as I read the situation, Theo has just hurled vitriol at them for specifying a completely reasonable feature that the openSSL team implemented incredibly poorly.
It's a feature that had a sensible use case in DTLS (datagram TLS, TLS not run over TCP). It's unclear as to whether the use case was best addressed at the TLS layer, whether it could have been specified as something run alongside TLS, or whether it was something that applications that cared about path MTU could have handled for themselves.
The TLS WG actively discussed whether Heartbeat had reasonable use cases in TCP TLS. Some people agreed, some disagreed. Nobody threatened a temper tantrum if the feature was added to TCP TLS. Therefore: the extension was specified for both TCP TLS --- which does not need extra path MTU discovery, and which already has a (somewhat crappy) keepalive feature --- and DTLS.
The larger problem is in treating TLS like a grab-bag of features for corner-case applications.
I still don't agree with the OpenSSL implementation being reference spec if you were refering to that as pygy_ pointed out. Unless the IETF released that code as an institution, I would consider it the same as any other 3rd party implementation - ie. not necessarily correct. How am I to know that the RFCs author wrote it unless I go digging? Why should I trust anything they wrote which may or may not have gone through any rigorous checking?
This isn't so much directed at you, tptacek (since your pedigree is well known), as it is the others bashing the IETF for implementation flaws - bash them for what they actually did and perhaps instead of getting angsty at the powers that be, try getting involved in projects like this if you believe they are so important.
(HN feature request: soundbits.)
This whole approach to diluting ostensibly one of the most important standards is beyond unprofessional, it's an example of failures on many layers of meta.
I would really like to see a compelling alternative to keep TLS honest, perhaps with Convergence-like ideas and bare-bones level of features.
The problem is always adoption, corporate fear of change ($upportabi£it¥) and endpoint adoption, but the threat of an alternative might be enough to scare the bejebus of the WG back to task.
It was actully included in OpenSSL before the RFC was published.
Both the RFC and the code were written by the same person (who denies planting the bug intentionally).
Now, a 64kbyte payload, that's unnecessary for simply making each packet unique. That size was likely chosen to allow for the path MTU discovery aspects.
One could argue, however, that "keepalive" and "path MTU discovery" should not have been commingled, but they were.
That dynamic reminds me of the bias labeled "sympathetic point of view" as described in the essay "Why Wikipedia is not so great": "Articles tend to be whatever-centric. People point out whatever is exceptional about their home province, tiny town or bizarre hobby, without noting frankly that their home province is completely unremarkable, their tiny town is not really all that special or that their bizarre hobby is, in fact, bizarre. In other words, articles tend to a sympathetic point of view on all obscure topics or places."
That is surely not how we want decisions made about TLS.
How I compile OpenSSL. 
( export CONFIGURE_OPTS='no-hw no-rdrand no-sctp no-md4 no-mdc2 no-rc4 no-fips no-engine' \
brew install https://gist.github.com/steakknife/8228264/raw/openssl.rb )
no-md5 doesn't currently work:
"_EVP_md5", referenced from ...
enveloped content test streaming S/MIME format, 3 recipients: generation error
Its small modular documented and tested.
We would all reach further by improving polarssl than starting another library.