The best explanation I can think of, being a software developer myself, but not having seen the code in question, is that the "player" object and the "ship" object are tied together a lot more closely than one might think, meaning that allowing the helm to be turned over to another player would require re-initializing way too much of the client program. Given that there's already enough flexibility to support fighters and the SRV, this doesn't appear to be the case, but I can only speculate as to how the code for the game is actually written.
It's also possible that the way commands are handled would have to change in order to implement limitations on what a player can do with a ship he or she doesn't own. For instance, currently, there's presumably no permission checking when issuing commands to the ship because it's just assumed that the current player owns the current ship. If it were possible for a different player to take the helm, there would likely need to be some set of controls that are off limits (such as self-destruct) to guest players. This could conceivably require a check for every single input, or some sort of configurator, to say nothing of who is responsible for collisions, or getting slaughtered for firing on a ship too close to a station and so forth.
I can totally see why the devs might say "Yeah, that's way too complicated. We'll just tack on a gunner mode."
Let's stop guessing for a moment here.
Player object and ship object are tied together is the assumption, but we have proof that is not the case.
If your ship gets blown up while you're in an SRV, you do not go to the rebuy screen.
When you dismiss your ship in an SRV, it despawns. It doesn't just conveniently hide out of sight, it is deleted from the game instance.
No entity is needed to replace you if you choose to fly an SLF with no NPC crew to pilot the mothership. You just slip from one to the other effortlessly.
Players can assume control of another player's SLF, so the re-initializing that you're worried about is already occurring during other events in the game. It's proven possible.
You don't need to limit functions such as self-destruct, even if that was an issue. Arguably, if you can't trust the person you're handing control over to not spit in your face in such a low-brow fashion you shouldn't have handed control over to them in the first place. However, if it is an issue just "hide" the features you don't want appearing on menus from appearing for people who don't need to see them. In this scenario you don't need to check who is in the pilot's seat and then determine what options they have. Assuming the multicrew member had LEGS that he could use in SPACE (Waiting FDev...) and walked over to the helmsman's panels, which he could see since they are activated by proximity, the option still wouldn't appear to him because he is not flagged owner.
There is no reason to swap the ownership flag from player to player. Input controls are the only thing that need to be transferred, and we already have multiple instances of controls being transferred from vehicle to vehicle, and soon multicrew position to multicrew position (Idle, SLF, Gunner) so that's not an issue either.
All fines and bounties are already shared between all multicrew members, so that question has been long answered.