The TLS/SSL and DNS carveouts are pretty normal. There are a million security options for those services and enabling them all would often mean denying access to anyone running a browser/client more than a few weeks old. Documenting them all would be a PITA so most policies simply prohibit them entirely.
Testing against customers is also a common prohibition for obvious reasons.
Hm... not normal in my experience. Not enabling a config is not a vulnerability in itself. If not enabling something means a security guarantee is broken (Eg: videos are accessible) then it is a vulnerability, and typically included in VDP, atleast VDPs that are in good faith.
There are a lot of theoretical vulnerabilities in various encryption algorithms used by TLS/SSL/DNS. There are also older protocols that have known vulnerabilities but yet don't present a realistic threat to most types of services. I've worked for more than one company that had to decide whether disabling an algorithm and blocking 5-10% of your customers was worth the tradeoff. Having these debates with researchers is tedious.
That said, there are numerous options that should be enabled and several protocols that should be disabled. It just isn't worth the spam you get if you allow submissions for these type of issues.
Makes sense. Thanks.