Yes, because this was creating DDoS levels of traffic to podcast hosting providers. Now Apple simply pings madly away at all known podcast RSS feeds and updates clients when there is a new episode. What would be far greener -- and efficient! -- would be for them to get on board with PodPing[1] to not only deliver feed updates much faster but to use a tiny fraction of the resources they are using now to get it done.
Author here. This has never been a problem, both in terms of volume and cost. I host ~0.25% (maybe more? I haven't checked recently) of all podcasts listed on Apple and up to a few years ago, I wasn't even using a CDN. Two Heroku dynos at ~$250/mo (25 customer subscriptions today) running a Python back-end with no caching at all was able to keep up without trouble. In fact, the only reason I added a CDN was Heroku's infrastructure having spooky issues with that volume of traffic.
Podcast hosting providers larger than me running on their own hardware should have (had) exactly zero trouble.
It gets a bit complex if your hosting company supports dynamic audio/ad insertion depending on how you accomplish that, but as far as retrieving the RSS XML feed, that has no impact.
Such refreshs would be using If-Modified-Since, so shouldn’t cause substantial traffic.
Apple reality distortion to claim this is positive for them.