Nice of them to cause confusion to make phoning easier. No, corp.paypal.com/news or PayPal.com/corp/newsroom etc weren’t a good idea. I’d love to hear how decisions like this get made.

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.)

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.