While there are many good arguments to be made against AES in favor of ARX construction ciphers, the choice of SPECK for this is not okay. The correct choice of an ARX cipher would have been something like ChaCha20 or Salsa20.
The choice of algorithm is less baffling than the choice of mode of operation. When designing a new file system, why in world would you use unauthenticated XEX (or XTS) mode instead of an authenticated mode (SIV, HMAC+CTR, ChaCha20-Poly1305, Speck128+CMAC-Speck128 or whatever). It's not like you need a one-to-one block mapping between encrypted and unencrypted data — you design datastructures yourself, it's a new filesystem! Can't they afford additional 16 bytes?
1) Are built from constant time operations, which means they are naturally resistant to side channel attacks (timing, cache, power, etc).
2) Are far simpler in their construction. This makes them easier to reason about and analyze.
3) Related to #2, this also makes them really easy to implement, which means less likelihood of some coding mistake.
Beyond that, most recent ARX ciphers also have a few other advantages over AES. For example, Threefish has a built-in tweak field, which makes using it infinitely easier in practice.
EDIT: In case you're hungry for more detailed explanations, I highly recommend reading the papers for Salsa/Chacha and Threefish. They're very well written, easy to understand even if you don't have a lot of experience with cryptography, and they have sections that explain the design decisions in enlightening detail.
ARX constructions are also easier to tune for high software performance, and generally don't require special hardware support, because all CPUs already have fast ARX operations built in.
Firstly, it's ChaCha20. I don't think anybody in their right mind would advocate a 2 round ChaCha. Secondly, there _are_ steam cipher constructions to achieve the design requirements for something like TFS.
On the contrary, it makes it suitable for file systems! File systems are not block devices, they are data structures on top of block devices — it's the job of these data structures to keep stuff, such as data, inodes, and... keys, and IVs, and MACs, checksums, etc.
"If you’re encrypting a filesystem and not disk blocks, still don’t use XTS! Filesystems have format-awareness and flexibility. Filesystems can do a much better job of encrypting a disk than simulated hardware encryption can."
Edit 2: also check out bcachefs encryption design doc: http://bcachefs.org/Encryption/ (also not perfect, but uses proper AEAD — ChaCha20-Poly1305. I sent some questions and suggestions to the author, but received no reply :/)