I think you fail to see that there are several ways to deal with the growing UTXO problem. Here, I will describe just one.
UTXO commitments store a hash of a Merkle tree or similar structure containing the UTXO set in the coinbase of a block.
A validating node after a UTXO commitment soft fork can choose to download only block headers and the blockchain head’s coinbase transaction. A rule of the P2P network protocol could state that a transaction must include the outputs it spends as well as partial Merkle trees towards the latest UTXO commitment. This means that although a transaction would take a larger amount of bandwidth, as it has to be broadcast alongside its ancestors, the validating node would not need to store the UTXO set.
Now we can go through the whole technical discussion about how this changes Bitcoin’s security model, and we can certainly have a lovely debate on the subject and consider many alternative versions of UTXO commitments with different levels of compromise. Also, even in a post-UTXO-commitment world, there is nothing but time, memory, CPU and archive node availability keeping you from downloading the whole chain from Genesis and verifying everything, even if just to throw the UTXO set away in the end and perform validations from then on using the commitment hash.
At this moment I believe I should have proven my point to your satisfaction.