This approach (using a separate domain for content that isn't part of their service itself) has security advantages-- for example, this way a compromise of their news site CMS can't expose users' PayPal session tokens.

It's decently common for websites to do this-- this is the same reason why Github Pages is hosted at github.io rather than github.com, and why static blobs are at githubusercontent.com. Those have a somewhat different threat model than PayPal's news site (hopefully PayPal isn't letting any random person add news stories...), but the premise is the same: if the thing does not need authentication tokens for the main service, make it so that it's impossible for it to get them.

(You could get some of the same effect by scoping your cookies to a specific subdomain rather than allowing them to apply to all subdomains, but (1) that's not always how you want to structure your site, and (2) it's really easy to mess up and inadvertently scope a cookie too broadly (or for the browser to misbehave and send to subdomains anyways, which was the default behavior of one very prominent browser for a really long time). Using a different domain entirely sidesteps all of this completely.)

Maybe I'm missing something but you can't separate you're session and authentication with a different subdomain? Eg. My session on corp.paypal.com would be locked down to solely corp.paypal.com.

From a practical sense, what different does a subdomain and a dedicated domain offer if you're managing your certs correctly?

You can, but a lot of people lack the discipline to do so correctly. I'd prefer them to use corp.paypal.com, but as a security guy it's easier to just get them a separate domain and let them have their less-secured stuff completely isolated.

You can, but is difficult and prone to errors. Separate domains solve the root cause of the issue. The alternative is an entry on the public suffix list.

Which would not be easy to get, considering PayPal is not running a public suffix.

you can request entries on it, the list is not just for TLDs

Yes, but the list is for public suffixes, i.e. domains under which users can get their own subdomains.

From my point of view, a possible compromise of their news site CMS sees like a much less serious threat than phishing, so this seems like a bad tradeoff. If you're worried that cookie scoping will get broken, maybe you could have the news site CMS raise an alert if it sees PayPal-session-token cookie names.

This is common for corporate investor relations sites.

They serve entirely different audiences and are usually separately managed for the product sites, it’s also common for the latter to be blocked by the companies which are the target audience for the former.