TLDR it doesn't matter (if I guessed right)
openssl commandline does about 50 different things; only two of them take bulk input data:
enc to encrypt or decrypt a "file" or encode/decode base64 as a special case that isn't really encryption, and
dgst to hash and optionally sign or verify a "file". Of those only
enc produces output that could be useful to "overwrite" something, so I assume you mean that;
rand can also produce bulk output, but not tied to any input.
Second, the issue in the question you linked is delay due to waiting for a cipher data block or an encoding (base64) chunk over the network. If you are only concerned with getting correct output, delay doesn't matter, and if the source isn't remote, it won't be delayed anyway.
openssl enc using a block cipher and mode, particularly CBC which is the default, by default uses PKCS#5 padding (so-called; officially it's PKCS#7 based on PKCS#5, but many people including OpenSSL just say PKCS#5). This allows it to encrypt and decrypt any number of bytes of data that fits in an input and output "file" as supported by the OS and filesystem. The encrypted file (with padding added) is always an exact multiple of the blocksize of the cipher used. For password based encryption with salt, also the default, the ciphertext is up to 32 bytes longer than the plaintext, so on encryption you may need to allow for that.
If you specify
-nopad (for a block cipher/mode) padding is disabled and the plaintext must be an exact multiple of the cipher blocksize. If it is not, an error occurs and the output is incomplete -- although usually nonempty, which can confuse uncareful people or scripts/etc into thinking it is valid when it isn't.
If you use a stream cipher (currently only RC4) or a stream mode of a block cipher (CFB OFB CTR) no padding is needed or used and the plaintext can be any number of bytes (that fit in files). For PBE with salt, the ciphertext is still longer by 16 bytes. (Warning: some versions mistakenly list CCM and GCM modes as supported on
enc; they don't actually work if you try to use them.)
-bufsize is (only) the size used to read and write data. It need not be related to the cipher blocksize if any, although by default it is a medium power of 2 and the blocksizes of all supported block ciphers are small powers of 2 so they happen to divide evenly. The cipher logic handles large data as a stream broken into chunks of any size or sizes; only the total length matters. But it is less efficient to handle lots of small chunks because it does more calls to the C library and (often) OS.
cat piped into
openssl enc input is fine, although if it reads only one "file" there is no benefit over just making that file the (redirected) stdin of
openssl, or the
-in argument. Similarly there is neither harm nor benefit in using
dd if it just copies the data; if you use any of the other functionality of
dd like converting EBCDIC and/or fixed length records (typical of IBM mainframe data) obviously that is needed. And if you want the statistics about
1234+0 records in etc, you do need
dd or similar.