It looks like the answer is Server 2012 R2. 2012 R2 only includes the file share when there are an even number of nodes. So if DR goes offline then the file share will be included in the quorum until such time that DR comes back online.
It also looks like from testing that if you gracefully shutdown connections on secondary's then the primary stays up. So to run from DR for a planned outage means we could failover gracefully and then shut down the servers at the primary site. Because DR became the primary, it will remain up as the last node standing until such time that quorum is restored (and synchronization is complete)
The concepts of quorum, and owners are separate topics. Just because a member of the WSFC doesn't get a vote in quorum does not mean it can't own a resource. Additionally, SQL Server doesn't really play a role at all--the same concepts apply regardless of what type of clustered resource you're dealing with.
Quorum:
The quorum is the number of votes necessary to transact business on your WSFC. Depending on your WSFC configuration, voters can be nodes (servers), a drive, or a file share. You need more than 50% of your votes in order for the WSFC to be online. If you lose 50% or more of your voters, then the WSFC and all clustered services (including your FCI) will go offline and not come back until you have (or force) quorum.
In your configuration, you have a File Share Witness (hopefully in an impartial location reachable by both primary & DR sites), and you've also changed the NodeWeight to 0 for your DR servers. Rather than thinking of NodeWeight as "The DR servers don't get to vote," you should think of it as "The DR servers get to vote, but their vote doesn't count." They are still there, they're still part of the WSFC, it's just that the WSFC doesn't listen.
Even though the FSW isn't hosted on the cluster (or, perhaps, more accurately, because the FSW isn't hosted on the cluster!), it still has to be "present" to vote. Which brings us to the concept of ownership...
Cluster Owner/Host Server:
Your WSFC has a network name and an IP address. That name & IP has to be tied to a machine that is part of your cluster. More specifically, it can be tied to any one machine in your cluster. This is part of your WSFC.
In your scenario, your DR servers have no vote for quorum, but they still must be possible owners of the WSFC Host Server. If you manually fail over to your DR site (which will involve forcing quorum because you have zero voters in DR), then one of your DR servers must host the cluster name & IP. If it doesn't, then your cluster can't come online.
Your FSW is "owned" by the same server that owns/hosts the Cluster itself. Therefore it must have all servers, including DR, as possible owners. When you do force quorum and come online in your DR site, the WSFC is going to want to continue talking to the FSW.
Your original question:
...what would be the effect if I limited the possible owners to just
those nodes at the primary site?
I suspect that you would have problems when you tried to force quorum and bring your WSFC online in the DR site--though, that's just a guess.
From a SQL Server perspective, you just care that you have quorum and the WSFC is reliably up. If you're having issues in that area, I'd look at the specific issues to your reliability. In reality, you probably don't really care which server is hosts your WSFC (and FSW).
Best Answer
I'm going to assume that the 2 in DC are your favored site (I feel dirty typing that) and San Jose is truly only for DR.
That's a shame - if you were running Windows Server 2016 there is a cloud witness.
Quite literally... anywhere. The witness may act as a voter (if it has a vote, depends on if dynamic quorum is turned on, the current state of nodes and votes, etc.) and will be used for arbitration.
Doing a manual failover involves having quorum and a synchronized secondary. Nothing in there requires a witness.
Let's dig a little deeper. The point of having a witness is to help with having enough votes to keep quorum and for arbitration so that you don't split brain. Since you only have the single vote (I'm assuming defaults, here) in San Jose - it's a moot point. If you truly had a DR issue you'd have (from the point of SJC) a single vote out of a possible of 3, which isn't enough to have quorum and thus the cluster service would shut down. It doesn't matter what the AG settings are, that's how WSFC works. You'd have to force quorum, regardless of if you can see to witness or not.
We're not going to get into everything with WSFC but that's the gist of your current setup. Thus, I'd put the witness where it will do the most good, which would be at site DC.
What issue are you trying to solve? If you do a manual failover then it is implied that the replicas are synchronous commit and synchronized also that the cluster has quorum.
If the issue that you are trying to solve is that you don't want a failover to happen or you want the AG to stay in SJC after the failover - then yes, you'll need to adjust the node weight to 0 for the DC replicas. However, if this is done, you're a single point of failure again as any hiccup on the SJC node means your cluster is down (I mean, you removed the voters - we have a bunch of watchers but no voters).
In that case I'd do maintenance on a node at a time and keep it within DC, not immediately go out to SJC. You could also ADD a node at any time in DC just for the purposes of that. If you application or user base is mostly in DC, the added latency to SJC might not be palatable. I can't tell you if it will or won't be.
Summary: First I would try to keep the AG in DC and only use SJC as DR, unless all replicas are Synchronous commit, then it doesn't really matter. Taking away the votes would be beneficial in the case for keeping the cluster up, but still wouldn't help all that much.
"It depends™" Again, what are you trying to solve? I wouldn't over-engineer a solution to try and solve every possible edge case or problem. Have your top 3-5 true issues and solve for that.
So you lied to me! I see how it is...
Yes, you can and should absolutely use that location for a FSW :)