Of course, this isn't something that has a concrete right and wrong answer. It's more a question of how much you trust your subdomains. Personally, I think sharing that information should be a conscious choice when setting the cookies and not something that you let happen by default.
Disclaimer I work on App Engine.
https://www.bing.com/search?q=ip%3A216.239.32.21
https://www.bing.com/search?q=ip%3A216.239.34.21
Search in that same document for "naked domain".
> I'd like to map my app to a naked domain (such as http://example.com).
vs.
> App Engine does not currently provide a way to map static IP addresses to an application
the latter is that you own an IP and want to map it against your appengine.
the former is example.com -> appengine site.
(not related to google)
So you traded an intermittent problem (only relevant when an IP change occurs) for 24/7 guaranteed service outages for a (probably very) low percentage of your intended demographic.
Because I'm pretty sure we all know what I meant when I pointed out using Cloudflare means gaining a convenience at the expense of being at the mercy of third party outages.
In some cases a single edge case can be the reason to make a decision.
If your attitude is “working in 99% of cases is good enough”, that means over a long enough period of use, 100% of your users will encounter an edge failure.
The way to even have a shot at 99% of your users a good experience is to constantly let edge cases force your hand.
I'm a bit scale focused though. If your site is never going to need a CDN, you can of course pick aesthetics over serviceability. But if this is something you hope to one day get big, you might as well make an easy decision to prepare for it at the start. You will want to support any inbound links you get for as long of forever as possible, so it's nice if they are to the right hostname to start with.
"as far as a CNAME needing to point to another domain instead of an IP"
So, it's unclear to me who you're arguing with. I thought a post explaining why using a CNAME on an "apex domain" is potentially problematic might be helpful. Guess not.
As far as cookies are concerned, keeping them on the origin ensures they get passed to all subdomains, which is usually a benefit, as opposed to a problem -- which you'll discover when you need to restrict API requests on a subdomain only to logged-in users, for example. And as long as you're keeping your cookie payload small, like a session ID or two, there's zero worry about a performance hit.
And as far as a CNAME needing to point to another domain instead of an IP, has that ever been an issue for anyone? Genuinely curious. I'd never even heard of that until now.
Honestly, simpler is better and "www." is an unnecessary vestige from another era. I dropped it from my sites starting a couple years ago. (Obviously with a redirect in case anyone ever types it.)