Yes. Ingress/egress IP ranges should be something support can easily provide.
Most places I've worked have had public-facing documentation that was a tiny bit dynamic (or at least had the one page updated by a cron) for the page containing the gateway IP lists or equivalent.
How does that work with third party CDNs, ipv6, dynamically allocated IPs from services like API gateway/ALBs, edge locations, geographic differences in content serving and the ability to evolve all of those without breaking an explicitly defined “these IPs are ours” contract for your consumer facing product that 99.9% of your users interact with through a standard connection and no weird firewall?
It worked quite well when I worked for a place that did this. I imagine the experience is quite similar elsewhere.
For CDNs, one of two things will be true: the traffic/access will be primarily API-related and not involve a CDN, or a CDN will be selected by the business which itself publishes its origin IP addresses, and the business publishing its IPs will either embed or link to that information. Cloudflare, for example, does this: https://www.cloudflare.com/ips/. Most good CDNs are popular enough that their IPs will already be allowed by most restrictive network environments.
IPv6 can be handled the same way. Just publish a list.
Dynamically allocated IPs for cloud provider infrastructure should be avoided by mature companies. Edge load balancers which do not support this should be avoided. All cloud providers make this easy: AWS, for example, provides a range of products that can enable this, from GA to NLB-with-ENI+EIP-in-front-of-ALB to NAT gateways to good old EIP'd EC2 instances routing traffic.
Handling multiple geos is as simple as publishing multiple lists of IPs. In the worst-case scenario, a customer uses the wrong geo's IP to allowlist traffic, things don't work, so they select a different one. If it's a frequent problem you can spend some time/money to provide alternative DNS records which always resolve to the same IPs and customers who need custom network configurations will endure a little extra latency.
> 99.9% of your users interact with through a standard connection and no weird firewall
That's doubtful, incomplete, and highly depends on the business you're in. Many companies which host user content, especially when they're new enough that they may not have grown content moderation/compliance procedures, end up on blocklists (which, like firewalls, are easiest to poke holes through on a per-IP basis). Several other things I've observed that complicate the situation further:
1. Some residential internet service providers firewall and/or block traffic, which can affect significant numbers of customers. This is an awful and borderline-unethical practice, but it happens.
2. Some very large corporations put all of their employees behind a firewall (via LAN or VPN). If you sell software to businesses, it is a big problem when a all of a business's users can't access your product while at work. Additionally, business infrastructure components reaching out to internet services to do API-API interactions will often need their traffic allowlisted by destination IP when leaving corporate infrastructure, and your gear will definitely need stable origin IPs if it ever initiates communication with business infrastructure.
3. Even if you're right and a statistically insignificant number of your users are thus affected, if you use dynamic IP addresses, that can change at any time. IPs associated with malicious traffic can be re-used by cloud providers. Even with non-reputationally-compromised IPs, for certain (usually non-HTTP) types of traffic, residential or corporate firewalls can make highly irrational/inconsistent decisions when deciding whether to allow traffic to an IP they haven't previously seen, even if the traffic in question is already common on the network. While such failures due to IP switching are rare, they're also very expensive: it really sucks to have to apologize to customers because you rotated out a load balancer or whatever.
Because it completely misses the point that it’s a lot of work that constricts future paths by forming a public contract that offers effectively no benefit to Spotify at all.
Those kids are going to pay for Spotify anyway regardless of if their weird school firewall comes up with a “this site is blocked” message or not. Phones and 5g exist, plus the school gets the ire for blocking it and not Spotify. And no residential ISP is ever going to block Spotify.
Most places I've worked have had public-facing documentation that was a tiny bit dynamic (or at least had the one page updated by a cron) for the page containing the gateway IP lists or equivalent.