When doing so, an attacker can steal cookies, and/or invoke APIs for the user.
Now, there are of course ways to avoid that, but in the end, if every other system fails, being on a domain without any API and without any sensitive content allows reducing the blast of the impact.
Real-world example: https://gitlab.com/gitlab-org/gitlab/-/issues/200094
GitLab has APIs under their main domain. Due to a misconfiguration, it was possible to render in the browser user-generated `.svg` files. Thus, a malicious crafted SVG file could bring to a XSS, and accessing a lot of personal user data on the main domain.
There are technical reasons for the shared domain, but if that particular API call was on another domain, the impact of the vulnerability would have been way smaller.
The point is: if for any reason (0-day, misconfiguration, bug, whatever) the content uploaded from the user is executed by the browser, instead of being "just" rendered or downloaded, it must execute in a different domain. Given domains are sandboxed by the browser, a vulnerability on domain A cannot affect domain B.
Of course, there are still way to shoot you in the foot (e.g., having the same access token in the cookies for both domains), but it's one measure more. This is why security should be layered, and you shouldn't rely on just one defense: https://en.wikipedia.org/wiki/Defense_in_depth_(computing)
Having a total different domain help highlighting that it is not official content.
There's probably some benefits around blacklists too.
For example if a user uploaded questionable content to assets.example.com/uploads, such as pirated content then someone could submit that to search engines and other lists to get your domain blacklisted. It's quite possible these blacklists could be related to the apex domain, not necessarily the sub-domain. A separate domain guarantees your apex domain won't get penalized.