Running multicast or multicast based routing protocols does not necessarily require GRE-over-IPsec. "Tunnel based" or "route based" VPN (
tunnel mode ipsec ipv4 a.k.a. IPsec Virtual Tunnel Interfaces in cisco lingo) will transport multicast and EIGRP or OSPF happily.
However, GRE is needed when you need to run non-IP protocols across IPSec:
At my former employer's, we used to run MPLS-over-GRE-over-IPSec extensively, mostly with EIGRP on GRE as the GRT routing protocol, and with certificate based IKEv1 and IKEv2 beneath it.
This enabled us to have a multi-VRF CPE as small/cheap as a Cisco 890 series at the customer site, while allowing for path isolation or "zoning": one VRF or "zone" for the ATM, one for video surveillance, one for internal data, one for guest WiFi, one for facility management, etc.
At the same time, these IPSec tunnels were used over almost any flavour of underlying transport (dark fibre, lit fibre, point-to-point L2VPN, multipoint L2VPN, L3-VPN, cable or xDSL internet, etc.
Of course, we would have preferred to run MPLS atop IPSec directly (
tunnel mode ipsec ipv4, see above), but IPsec has no support for MPLS-over-IPSec (I believe there is - or was - an RFC draft for that, but it never made it).
Yes, MTU across the WAN is cut short to 1400 or less (minus 8 if the local loop at the customer's end is based on PPPoE!) with MPLS-o-GRE-o-IPSEC. PMTUd is further made difficult because the tunnel interface is not actually an IP interface anymore, but an MPLS interface. Therefore
ip tcp adjust-mss is without effect on the tunnel interface, and TCP MSS clamping has to be done on the CE facing interface.
Fragmentation of IKEv1 messages was also a difficult topic when RSA keys grew larger, eventually properly solved with IKEv2 and it's support for explicitely defining payload size (
crypto ikev2 fragmentation mtu <size>)