AES-XTS is a mode of operation of AES that encrypts blocks, but is not a blockcipher. It has the security drawback that when information in a large block changes locally (e.g. a single byte), it's possible to tell within which 16-byte sub-block the change occurred. The larger the block size, the more that's an information leak.
WCFB is a true tweaked block cipher. As such, there is no inherent security drawback with increasing its block size. The price to pay is that it uses the underlying block cipher about twice as many times.
For both kinds of block encryption, other drawbacks of increasing the block size $b$ are from the standpoint of the information system using the encryption.
Practical large block ciphers with adjustable block size, including WCFB, has cost of cryptographic operations per block at least (and about) proportional to $b$. Assuming this:
The cryptographic cost of reading (or changing) any small part of a piece of encrypted information increases about proportionally to $b$. For a video storage application, that unavoidably implies that the time for seeking to a certain point in the video grows about linearly with $b$. If the block cipher is used for disk encryption at a block level, the same linear growth applies to most file system operations, like creating a small file. In a sense, system response time to a given stimulus increases linearly with $b$.
The memory buffers needed for each file (and more generally piece of data) must be increased proportionally to $b$, otherwise performance is down the drain due to multiple encryption and decryption operations during linear access. And there are drawbacks to large memory buffers beyond the memory usage and the need to adjust it, including: more information lost in case of power cut, longer time to flush buffers, increased disk activity (and wear for Flash/SSD) per flush, all proportional to $b$.
Note: If the block cipher is used for disk encryption at a block level, and the file system and applications are unaware of the large block size, then the "down the drain" case is bound to happen. In particular, if a file system uses a certain block size for file allocation and directory chunks, it's critical that $b$ is a divisor of (including: equal to) that, and blockcipher blocks are aligned to file system blocks. That's both for performance and integrity in case of power loss.
If nothing special is made about memory caches built into the CPU, the amount of cache effectively flushed by a block encryption/decryption increases linearly with $b$, perhaps to the point of effectively flushing the whole CPU cache (or a whole layer of that). If we are in the above "down the drain" scenario, that cache flush effect will make things even worse. On the other hand, with large enough buffer, the larger $b$, the less frequent are cache flushes, thus this cache flushing will typically not impact average performance negatively for linear file access workload.
For the application at hand: if possible, perform encryption at the application level or file access layer (e.g. read or fread write or fwrite, or with an encrypting filesystem that encrypts at the file access level), where there is no need for large block size. This is what gives the best responsiveness, minimizes information loss on power loss, and often makes encryption the least costly overall. If you must perform disk block encryption (e.g. because you can't change an application, and can't slip encryption at the file access layer nor use an encrypting filesystem), then you must use as block cipher size some divisor of the disk block size known to and used by the file system, and insure alignment. Usually the best choice is whatever the underlying storage system uses at block size, like 512 bytes for many old consumer hard disks and many SSDs, 4kiB for many recent hard disks. If in doubt, use 512, which is unlikely to be disastrous.
For video encryption, AES (and derivatives) is a good choice only if there is hardware support for it, and it's used. Otherwise, modern ARX ciphers like Chacha are going to be much faster.
