One of the weird things about an encryption layer on top of a filesystem like eCryptFS (as opposed to encrypted block storage) is that it needs to encrypt and MAC the filenames somehow, but the underlying filesystem has maximum lengths on the filenames, so whatever space you're using for padding and authentication code needs to be squeezed in. And you also need to potentially find an encoding of the encrypted data in case the underlying filesystem doesn't treat filenames as bytes-except-for-ASCII-slash (e.g., common Mac and Windows filesystems treat filenames as Unicode of some form, and Mac ones even do canonicalization). So, your encrypted filenames end up being longer than your decrypted filenames, which means that your maximum filename length is shorter than the underlying filesystem's maximum length.

For a system like Dropbox, which automatically renames files to things like "file.txt (userbinator's conflicted copy 2018-12-25)", this is a problem. For eCryptFS, whose limit is "we typically recommend you limit your filenames to ~140 characters", (https://unix.stackexchange.com/a/32834), the uncertainty is a problem too.

Dropbox could make this work (and did in the past), but they decided it would be more reliable to say they won't try and won't make promises about their client working 100% of the time on these filesystems. (And I guess their support or business department was not thrilled with the option of "we'll let you try but we won't support you even though you're paying".)