you could even do the same in reverse and "import" sha256 commits in sha1 projects. the only real difference would be which one is used as primary key in git's internal store.
One of my theories (see my other comment) is that Linus and the people who took over Git fell in love with the implementation. A fixed size (160 bit) hash on the stack is incredibly efficient. A variable length record with optional fields isn't. You can do a byte-wise comparison of 20 bytes on a SHA1 hash. You can't if there are unknown hashes in there that might not break equality.
You should never let these kinds of implementation details drive the design at the expense of future compatibility. We were already aware of this issue in 2006. It happened with MD5 (to SHA1). So now we have some of the worst technical debt to be introduced in the 21st century and it's going to be a giant pain to fix. SHA256 will eventually fall by the wayside too so just changing the algorithm isn't the long term solution.