Bitcoin's blockchain is very much like a version control. It versions the unspent output database (and some metadata I don't know about) and blocks represent the deltas (commits or patches) to this database.
Now if you want to know the state of the system after 1000 blocks, you need to start from the genesis block, then download, verify and apply 1000 blocks (patches) to it. Now we are beyond 500000 blocks and syncing up new node takes ages.
Version controls solve this problem by inserting a full snapshot instead of deltas after several revisions so one don't have to apply all patches from first to last to get to the latest state. But this is not necessary.
It's enough if patches contain a hash of the state they are patching allowing the verification of the deltas themshelves. So if you have revision 1234 of the state, the patch that upgrades it to revision 1235 contains a hash of it. So the one who applies the patch can verify if they apply it to the correct state (it would be cryptographically very difficult to forge a different state that matches the hash and appear valid). So it's technically possible to design a system that allow syncing from the middle.
In case of the blockchain this would simply mean that instead of storing the hash of the previous block, it would store the hash of the previous state of the utxo database. This would mean that if I could download the utxo database eg. at block 500000, I could start apply the next 6000 blocks to it and reach the correct latest state without having to start from the genesis.
However the current design of blockchain doesn't allow this. You have to start from block 1 and catch up from that.
In 2009 when Bitcoin started version controls were probably well known already. And I think I wasn't the only one who suggested and discussed this. Probably there is a good reason for not allowing to start from the middle. So what's the advantages of having to start syncing from the genesis?