2 is fine with me, but if you wanted a compromise that would give the gaming experience a bit of the feel of not having instantaneous translocation you could do some of the following (some of which were already suggested up thread):
1) Fundamental idea: At the moment that you want to assign officers to an empty slot, you randomly determine where unassigned officers are, and then build in a distance-based time lag between the act of giving them their orders and the actual filling of the command slot to which they've been assigned. Possible locations are colonies or TG/Fleets. The commanders' location wouldn't be tracked while in transit; their location would simply be "In Transit" with an arrival time data member. I imagine the random location assignment would be triggered by e.g. opening the commander screen.
2) You could do the same thing for the possibility of getting killed when a ship or planet explodes/is damaged - the damage/combat routine triggers a reassignment pass.
3) The assign commander screen would have a lag time next to each officer, and could be sorted based on lag times, so you could prefer assigning officers who are on board. Until that time, the command slot would be filled by the commander, but with an "in transit" flag (so bonuses/risk of destruction don't apply). The idea here is that High Command won't be managing the location of every JG; an assignment to a slot will be filled more quickly if done from "on board" resources. If performance is a problem, you could specify a "max jumps" search radius to only present officers that are close to the command location (rather from the entire empire). If you did this, you'd probably want another mode for the screen that presented officers without displaying a delay (and only calculated a display when selected or assigned).
4) To allow High Command to stockpile special officers (and to give micro managers more control) you could add an "officer pool" category of assignment to each possible officer location to which the player can assign officers. This would have transit time just like a "real" assignment, but would not be overrideable by the random assignment phase, i.e. this is an officer that High Command (the player) IS paying attention to and wants in a particular location until further notice (presumably as a reserve or for a future change of command).
5) Resolving the "in transit" state for a commander could require going into the same system as any colony after the lag has expired (I'm not keen on this one - I think it's in the same category as over micro-management of maintenance).
6) You would probably want to have a minimum time delay between calls to the random location assignment routine (e.g. a week) so that opening then closing the commander screen wouldn't magically teleport people all over creation (and/or so that commanders don't magically appear/disappear on board ships between hits). There could also be an explicit "update commander locations button" that could be used to more frequently update, or even as the only way to move people.
7) Probability of a commander being at a particular location could be dependent on the planetary population size, fleet tonnage/military presence (system defense score), whether a HQ is present .... Presumably Fleet and/or sector HQ would have a very high weight.
8 ) Slightly more tracking, but a bit more realistic, would be to have every officer always be assigned to a location (either "present" or "in transit"), and the random location assignment phase would actually be a "generate commander relocation orders" that would randomly assign a small fraction of the commanders to a new location and put them in transit. This presumably would be done during the weekly update phase. This might actually be less coding, since commanders would only have two states: "present" or "in transit", while the other situation has to deal with "location unknown" through the random assignment stuff.
9) I can already hear the calls from people saying "If you put any of this in, please put in a flag that gives us just a raw behavior #2"
10) Survey teams could presumably be set up to use the same "lag time" mechanism if desired.
So the 50K view of the above suggestion (especially with #8 included) is to NOT abstract away the location of commanders, but to abstract away the travel mechanism in favor of a magic lag time. This knocks out the instantaneous teleportation aspect, while not getting snarled up in tracking the actual motion of the officers, which is where I suspect most of the coding complexity that you're worried about would come from.
That being said, even if you like it I think this is probably a "should have" (i.e. should wait until after 1st release), since #2 would get the job done and can be enhanced to use this mechanism at a later date.
PS - While reading this, realized that you probably want life pods to implement both "IHasLocation" and "IPotentialCommanderLocation" (or whatever you're using for these abstractions), since they're a place commanders might end up.