I don’t think the ros1_bridge is “short term”. I expect it to be around and useful “forever” since there will likely always be users which use the benefits of both system and want to bridge between them.
First of all this would imply that the message classes share a common base class (requiring changes to ROS 1). It would also require the base class to have a vtable (and least for the destructor). And the functionality in the base class would be dictated by the lowest common denominator since it needs to be available in both ROS version (currently ROS 2 has additional features like default values for fields). And at the end of the day the code creating the messages still needs to decide which subclass it wants to instantiate. Some a user who only wants to use one system (ROS 1 or ROS 2) that is a lot of overhead which I don’t think is reasonable. It also couples the two versions in a way that separately evolving them will be difficult / impossible. If we want to introduce a fancy new feature to .msg files in ROS 2 it will also be necessary to do the same in ROS 1. This is one of the things we strongly want to avoid since stability and robustness is very important to the ROS 1 community.