As the article explains, the problem is that SWF files hosted on one domain can execute in the security context of that domain, even when embedded in a page on a completely different site. So allowing attacker-controlled uploads makes any credentials on that domain, such as session cookies and CSRF tokens, vulnerable. If the SWF is hosted on a domain with no sensitive credentials, this particular problem goes away.
The Symantec article is interesting but only says the fake page is hosted on "Google's servers", not "google.com", but users might believe "googledrive.com" is trustworthy.
Browser security relies on the "same origin policy" which says that certain operations are restricted to only access resources in the same domain as the active page. In particular, you can't read cookies from another domain, and you can't read the responses of authenticated HTTP requests. XSS and CSRF attacks all rely on an circumventing this protection in various ways.
In this case, Flash considers the origin to be the location of the SWF file. This is different from normal JavaScript where all scripts in a page run under that page's origin, no matter where they're loaded from.
It depends on the attack you're trying to prevent against.
The blog post in the OP solely discusses XSS vulnerabilities that are introduced by unrestricted file uploads. There are numerous other issues that can occur from arbitrary file uploads (malware hosting, arbitrary code execution if it's PHP, phishing), but to prevent against a user content ever reaching sensitive data via XSS, placing all user data on a separate domain is pretty much your best bet.
Indeed. Nothing about this applies to sites that accept uploads for internal use (e.g. parsed as input data).