Many have complained about that and I am not aware of any work-a-rounds. Camera behavior is part of the Orbiter. We can't override the camera behavior from the client side without causing lots of unintended side effects.
I see. Well, another problem of changing a feature and causing side effects. :-(. In Orbiter 2010, camera was not tied to Size - so Size value choice for the vessel could be influenced by other, more subtle considerations. For example, for a 3-stage rocket, it often helps to select same Size for all stages (and even for payloads) to avoid camera/view jumping radically upon each separation. With same sizes, you get smoother visual experience through the flight. And, as stages get smaller, you just move the view closer manually - but only when you want it, on your conditions. But now single Size selected for the biggest stage prevents you from zooming in later.
Then, there is a lock-in effect. My full collection is now over 100 individual vessels. Tweaking Size value for each of them is daunting. But worse, I have about 500 scenarios - each carefully set for comfortable and pleasant initial camera placement. Changing Size for focused vessels will hopelessly screw these starting views.
I think, the only way for me is to address it programamtically, in the library. I already have a deferred sizing change after pilot ejection on Vostok, that I was already planning to make common for all vessels. Now I'll have to somehow protect initial scenario sizing and resize to a tweaked Size (or maybe Size2) at some convenient point later in simulation... or leave it fully to the user action (whenever he wants) by some key combination... We'll see - that's likely for later, not for the current installment. Except maybe for launchpads - I want to shrink their Size after launch saw they'll disappear from view faster.