I’m skeptical that you’re giving the full story
No, you’re right. There’s a much bigger story here. I was just trimming out a lot of it since I don’t normally run into people who can follow along easily. Akamai, for example, uses the proprietary AKAMAICDN record to allow the functionality of a CNAME. For example: foo.com AKAMAICDN’s to foo.com.edgekey.net (edgekey.net of course being the Akamai edge server suite). So someone using Akamai can do that to allow them to use the apex (but will still very likely have a www.foo.com CNAME foo.com setup to catch people who did a www anyway) Cloudflare uses CNAME flattening to “cheat” the CNAME rules by doing the CNAME DNS lookup internally and pretending to be authoritative for the request.
You don’t typical have your webpage itself delivered by CDN, you have your static assets delivered by CDN. Why can’t you put your static assets in a subdomain that gets a CNAME?
You can most certainly put static assets in a specific subdomain (and in fact, that’s how most setups are), but the CDN itself often requires handling the entire request at the beginning. You don’t want, for example, an A record at the apex pointing directly at your origin servers (terrible idea for security & performance; kind of defeats the purpose of the CDN), instead you want the user to connect to an edge server and have that edge server immediately serve the static content while the origin is contacted by the edge server for any non-static content that the user needs. This allows the CDN to do their cloud magic while your origin servers can do as little work as possible with as few people as possible. Effectively, you can block all requests to your servers that are not from your CDN. Many CDNs these days are also a major security feature.
One in the hand is worth two in the bush.
Sell it. Invest that money in a less risky asset. You win no matter what that way.