There is still an open issue in VeraCrypt (https://github.com/veracrypt/VeraCrypt/issues/136) because of which BitLocker is much faster on SSDs then VeraCrypt... But if you don't need those speads, VeraCrypt is still great...
The principal difference is the native speed of raw IO - NVmEs are an order of magnitude faster than SSDs. TC/VC don't use hardware acceleration, so all the encryption work falls on the CPU. On a machine with a reasonably modern CPU, TC/VC run nearly at drive's native speed.
No, that's wrong. VeraCrypt uses AES-NI when available. It seems the source of the issue is the IO design of the driver, which causes unnecessary context switches when operating on a raw device.
You can also explicitly disable the AES-NI in Veracrypt and use pure software implementation if you don't trust the hardware. I usually enable this option.
You could probably imagine the possibility of state actors and Intel, for example, conspiring to backdoor AES instructions of specific targets. Maybe possible with the IME. Not accusing them of this, but it's not out of the realm of possibility. The only things using the AES instructions are important data needing to be encrypted.
On the other hand, trying to backdoor XOR would give you an astronomically higher amount of white noise. Finding important data mixed in with all the other things a computer XORs would be much harder.
The principal difference is the native speed of raw IO - NVmEs are an order of magnitude faster than SSDs. TC/VC don't use hardware acceleration, so all the encryption work falls on the CPU. On a machine with a reasonably modern CPU, TC/VC run nearly at drive's native speed.