The assumevalid feature still checks that all transactions’ content matches the corresponding txid and that all txids are committed to by the block. This already guarantees that you get exactly the same blockchain byte-by-byte as everyone else on the network. It also runs most of the other checks transactions and blocks. E.g., that transactions are well-formed, there is no double-spending, the proof-of-work rules, block weight limit, etc.

The assumption that assumevalid makes is that the scripts in the transactions are valid, i.e., that the signatures, input scripts, and output scripts would evaluate satisfactorily. This assumption is reasonable, because the transactions are buried by months of proof of work (or however much time you set a manual assumevalid point into the past), and the entire network has been building on these transactions for months. If any of the scripts had been invalid, nodes should have rejected the transactions months ago. It would be entirely unexpected for anyone to spend all this proof-of-work to extend an invalid chain. However, this does represent a (small!) security reduction traded-off for a big speed-up.

Even if you configure a custom assumevalid hash, your node will always follow the most-proof-of-work chain it learns about. If the configured hash is not in the chain your node is processing, it will do full script validation for the entire blockchain instead.

Either way, you always trust the software you’re running to work as advertised. If the software is malicious or has defects, you could have any sort of unacceptable behavior, so that’s not a new assumption.

Checkpoints are a related but different concept which Bitcoin Core no longer uses.