Q: My question is this: Is it better for performance or any other reason to host both the API and the SPA on the same origin?
It's not a matter of performance. Security and performance rarely get along. I would dare to say it's a matter of convenience. Organising applications under the same "umbrella" (domain) ease the handling of CORS, cookies and session reuses (SSOs). From the company standpoint, it looks more corporative too. On the other hand, it's cheaper having a single certificate (for the TLS) than one for each domain. Not to mention the burden of having to track the expiration of each certificate and its renewal. Take StackExchange as an example, +100 different subdomains under the same origin
Deploying both applications under the same origin doesn't require us to deploy and run both on the same host or network. They can be deployed and run in different environments and still work under the same origin (this is fairly common on the cloud). So, working under a common origin (domain) doesn't guarantee better performance. It could if both applications were deployed and run one next to the other or at least within the same infrastructure.
Q: Should I avoid using CORS if possible?
As any security solution, it should be studied and adopted according to real threats and vulnerabilities. Since CORS is configurable, I would not remove it totally. Even if our SPA is the only client, the API is still public and it could be interesting for you to have a security resource to limit the access to the API.
If you make it configurable, you can adopt different configurations for development, testing and production without too much overhead. In the worse case, disabling CORS would take a special configuration such as
Additionally, CORS can be handled at the Web (HTTP) tier instead of at the application tier. Handling CORS at the web tier extends the security to other areas (other APIs, sites, blogs, etc) within the same domain. In other words, a single point of failure but also a single point of configuration.