Too inconvenient to program. You'd have to program actual dropships instead of an abstraction as well as determine how well they do in a ground combat engagement. Steve wants to avoid that mess, hence the abstract 'drop' mechanics and the presumption that ground forces do not defend dropships after the drop since they are expected to either see those things leave or won't be picked up any time soon and will abandon them for better positions.
I don't understand why this should be any more complicated to implement than other solutions. It is a design consideration.
I know that Steve wants to keep it simple, but my feel is that 'abandon drop' will be used exclusively against defended targets. If this always damages the bay, and you can only fix it at a yard, there is no point in building non-drop bay equipped transports ever, making it pointless to even implement those. Abandon or wait feels like inflexible handling of drops when you need them to just wait five more minutes somewhere to improve your schedule.
Also, the combat drop is one of the central elements of any assault, and we are getting all the fancy options of non-abstract combat troops. Having abstract drop ships still does not feel adequate to me. Some types of infantry and vehicles may drop directly from orbit, some flying vehicles may be able to achieve orbit again under their own power.
As I understand it the aim is for the mothership to be at risk while it is launching the drop pods. If the drop pods were independent then the logical decision is to give them a bit of extra fuel on so the mother ship could stand off from the planet and launch in safety.
Which IMHO would be the sensible thing to do in the first place. And there again Aurora usually gives you the building blocks to build what fits your doctrine and gives you options to try out. Forcing the mothership into danger feels still just wrong to me.