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.