Interesting question, one for which I can hopefully give an equally interesting response
. I'd say in this day and age, the settings you mention here aren't really considered to be as big a security hole as they once were, depending of course on how a network has been configured. In older times when firewalls were a lot more basic and less widely used, having a network with few security restrictions in place which also sent replies on ICMP could give away many details of the network.
One method would-be attackers can use is to perform a network sweep with tools such as Nmap, which will attempt to ping whatever it can and analyse the ICMP response packet. Each OS implements ICMP packets in a slightly different way - still following RFC and giving all relevant details in that reply, but constructed differently enough to reveal which OS is sending that ICMP reply. So, what attackers can potentially gain from ping sweeping a network, is to see which machines reside where, and what OS they run, thus giving clues on potential attack vectors.
As for Forward PathMTU Discovery, this hasn't really been so much of a security issue. There are some techniques which can exploit it, but they are incredibly complex and hard to implement, and typically rely on Man-in-the-Middle and replay style attacks, which typically need direct exposure to the target network or a means of intercepting traffic directly before it reaches the network. What PathMTU Discovery does rely on however, is Forward ICMP Errors in order to function, as it relies on a specific type of ICMP response for the technology to work.
In other words, you can't have one without the other, and if you rely on PTMU, then you need ping response. Even if you aren't using PTMU, there are various other standardised technologies which make use of ping response in order to adjust how packets are sent, which you seem to be encountering issues with when ICMP isn't allowed through.
Given that you are considering the possible security risks of allowing ICMP through however, I'd imagine that you likely have a tightly tuned network, allowing only what should be allowed through. This would likely involve restrictions on who gets to send traffic to whom, which ports should be allowed, and possibly using UTM features such as anti-virus and IDP. If you are using such features and have a network configured like this, even if an attacker can see what a network looks like, they can't do anything with it since they'll never be allowed past the firewall. To make things even harder for attackers, most web traffic is encrypted nowadays, be it through HTTPS, TLS or some form of IPsec tunnel.
So, with this in mind, if you feel safe enough to allow ICMP through (and/or PMTU Discovery), there are some things you can do to help secure the network from potential attackers. The first is to make sure you have a sufficiently high TTL value configured, which should prevent attackers from making it past the first few hops. If you consider most attackers will typically come from outside, likely another ISP and/or country, they will have reached at least our default TTL of 3 (likely more like 10-20 hops), and exceed the MinTTL value and thus not respond. Second, you could make use of threshold rules to ensure any aggressive ping sweeping is temporarily blocked.
As for predefined settings, the only way to configure PTMU Discovery and Forward ICMP Errors is to enable it per-service. This is easy enough to do though, as you just need to enable the 2 checkboxes for whichever service you wish to use with an IP Rule/Policy. You can find services under Objects > General > Services under cOS WebUI, then you simply go into the service in question and enable the settings. The only reason we don't have a "cover all" setting is due to flexibility, as there may be some occasions where it's desirable to disable PMTU for example.
So, hopefully this addresses your questions, but if there's anything more you wish to know or something I can help you with, just let me know.