To be more clear for those less familiar with the operation modes of block ciphers, the CTR mode allows encryption or decryption at arbitrary positions in a text, in a random order, exactly like the ECB mode.
Moreover, the implementation of the CTR mode is trivial when an ECB function is available from a library, a CTR encryption or decryption is done by invoking ECB on some non-repeating value, e.g. the value of a counter incremented after each encrypted block, and computing the sum modulo 2 (a.k.a. XOR) with the plaintext (for encryption) or ciphertext (for decryption).
For random access, an appropriate offset is added to the counter.
When the threat model for a SSD or HDD is only that it might be stolen, the CTR mode is a perfectly secure method to encrypt the SSD or HDD, using the sector number as the counter value.
The slower and more complex encryption modes that have been standardized for full disk encryption, and which are used in most full disk encryption programs, are conceived for the use against a much more powerful opponent, who is not just a thief but who is someone able to access the SSD or HDD frequently, for many weeks or months, without the knowledge of the owner, and who will be able to frequently make snapshots of the SSD/HDD as it evolves during that time, to be analyzed for values that change in time, which can reveal differences between the corresponding plaintexts, which might allow the plaintexts to be guessed (i.e. if a text file is edited frequently, the content of the parts that change between versions might be guessed by the opponent who watches the SSD).
This threat model is valid only for someone who is a person of interest for the surveillance by some TLA.
It does not take a state-level adversary to watch changes in a disk over time. It's a pretty basic cryptanalytic setting to operate in. You're talking about XTS vs. CTR; the problem with XTS is that it leaks in way that somewhat rhymes with what ECB does, and of course the much larger problem is that none of XTS, ECB, or CTR are authenticated --- an adversary with durable access to your disk won't bother trying to cryptanalyze it, because it's easier to compromise one of the executable binaries running on it by manipulating the ciphertext.
All of these are reasons why you want to avoid using full disk encryption outside of the narrow problem of your laptop getting stolen out of the back of your car or something.
I agree that full-disk encryption (i.e. encryption inserted in the block device driver) is not the right solution for storage encryption, and also the encryption at the file level is not a solution.
The right place where storage encryption must be inserted is in the file system implementation, where it is possible to implement a completely secure form of authenticated encryption. This is especially easy to do in the so-called copy-on-write file systems or log-structured file systems.
However, file system implementations are much more complex than block device drivers, so modifying them to insert encryption in the right way requires a lot of work, which nobody has done for any of the popular file systems.
While there are some commercial solutions that claim to be secure I have not seen anyone that manages the secret keys correctly (no secret keys should be stored in the encrypted device itself, regardless if they are encrypted with a password, because encryption based on a password is much weaker than with a long random key).
Moreover, the implementation of the CTR mode is trivial when an ECB function is available from a library, a CTR encryption or decryption is done by invoking ECB on some non-repeating value, e.g. the value of a counter incremented after each encrypted block, and computing the sum modulo 2 (a.k.a. XOR) with the plaintext (for encryption) or ciphertext (for decryption).
For random access, an appropriate offset is added to the counter.
When the threat model for a SSD or HDD is only that it might be stolen, the CTR mode is a perfectly secure method to encrypt the SSD or HDD, using the sector number as the counter value.
The slower and more complex encryption modes that have been standardized for full disk encryption, and which are used in most full disk encryption programs, are conceived for the use against a much more powerful opponent, who is not just a thief but who is someone able to access the SSD or HDD frequently, for many weeks or months, without the knowledge of the owner, and who will be able to frequently make snapshots of the SSD/HDD as it evolves during that time, to be analyzed for values that change in time, which can reveal differences between the corresponding plaintexts, which might allow the plaintexts to be guessed (i.e. if a text file is edited frequently, the content of the parts that change between versions might be guessed by the opponent who watches the SSD).
This threat model is valid only for someone who is a person of interest for the surveillance by some TLA.