The SSL test of htbridge pointed out that the server supports the elliptic curves but not the EC_POINT_FORMAT TLS extension.
What does that TLS extension protect against? What is the (potential) risk of not using it?
TLDR: not much
Sending the extension is basically to inform the peer whether you support compressed points, since support for uncompressed points is mandatory (if you support EC ciphersuites and certs at all).
If you don't support compression and don't send the extension, there's conceivably a risk the peer may send you a cert/chain and/or ephemeral key that uses compression, which you cannot process so the handshake fails, even if the peer might have been able to use an uncompressed-point cert/chain and/or key or some other negotiable ciphersuite that would have worked. But RFC 4492 5.2 explicitly prohibits the client from doing this, and general Postelianism should discourage the server although 4 is at best ambiguous. Not to mention I've not seen any implementation of EC that doesn't support compression in the first place.
If you do support compression but don't send the extension, there's a risk the peer may fail to use a cert/chain with compressed point(s) even though you would have accepted it. If it does not have another cert/chain (and related parameters if applicable such as DHE) for a ciphersuite supported by both parties, this may mean the TLS connection fails entirely, and depending on the systems and users involved, might provoke them to use alternative communications that are insecure or less secure. If it does have another cert/chain without compression and is able to complete the handshake, it wastes a very small amount of bandwidth which almost certainly doesn't matter and the resulting connection might possibly not be as strong as it could have been, but if both parties are configued and implemented correctly it should still be sufficiently secure. There should not be any issue with the ephemeral key because the server can decompress that if necessary.