I don’t think there is definitive answer (there might be old discussion buried in some ticket), but I can offer some historical perspective.
WordPress didn’t start with Custom Post Types. They were relatively late addition. While they were modeled after native post types, those still remain kind of special case.
So the concept of such split was kind of already in place — post data was stored in database and logic governing it was stored in runtime code, before CPTs even existed.
In addition WP hooks system and plugin activation/deactivation favor runtime code approach as well. Implementing activation/deactivation in plugins is kind of clunky and most plugins simply don’t bother with those routines. For a long time themes didn’t even have a way to run activation/deactivation logic without some creative hacks.
Additionally post registrations contain localized strings and WP localization workflow works by extracting strings from source code. Storing those in database would require having two different workflows for compiling list of localized strings. As well as hugely complicate their changes on updates.
In a nutshell — the implementation is simply consistent with WP history and typical practices.