Not only does compressing the ciphertext not make ECB secure, but it actually makes a secure cipher like AES-GCM insecure by leaking the content of the plaintext through the message lengths as in the CRIME and BREACH exploits.
If you are tempted to ‘increase the strength of ECB’, consider stepping back from minutiae like ECB for a moment to review your broader goal. There's a whole literature out there of ways to build authenticated ciphers—which are the black boxes that take keys and messages and turn them into ciphertexts that keep your conversations secret and detect forgery—with various performance characteristics. If you want to keep up with it, you might follow the IACR ePrint archive.
Forget, for a moment, that the concept of ‘block ciphers’ exists. Focus on authenticated ciphers: if you insist on block ciphers, you'll rule out some of the most popular and highest-performing authenticated ciphers like ChaCha/Poly1305, which, as it happens, can exhibit an essentially arbitrary degree of parallelism.
Next, is parallelism your goal, per se, or is performance your goal—in terms of latency and throughput? Let's take a look at the standard cryptography benchmarks which use a consistent framework for performing fair measurements across a variety of machines. It's a high-dimensional space that's difficult to navigate, which is why there's a large literature out there.
For example, anything based on AES will have a wide gulf between (a) hardware implementations that are fast and secure, (b) software implementations that are slow and insecure, and (c) software implementations that are painfully slow and secure. (The scale of slowness may not be relevant to your application; what is more significant is that secure software AES implementations like BearSSL's are few and far between.)
This is also why there are only a few choices that have been widely implemented in software—notably AES-GCM and NaCl crypto_secretbox_xsalsa20poly1305 or variants like ChaCha/Poly1305. The CAESAR competition didn't really turn up anything much better for most users, and there's an ongoing Lightweight Cryptography competition if you want to follow an academic bloodbath of destroying security of novel ideas.
If you are writing software, you should just take one of the handful of secure authenticated ciphers that are ready on the shelf, like AES-GCM or NaCl crypto_secretbox_xsalsa20poly1305, according to engineering constraints, and pay attention to the security contracts. Considerations that might figure into this choice:
- Is one of these readily available in your software environment, and will that make the difference of whether you use cryptography or expose users to harm? If so, do that!
- Are you subject to auditors who insist that you follow US federal government standards and will look for AES-GCM? If not, consider safer options like crypto_secretbox_xsalsa20poly1305.
- Can you guarantee that you use AES-NI and CLMUL hardware support, or not? If not, consider safer options like crypto_secretbox_xsalsa20poly1305.
- Can you choose nonces sequentially, as in a sequential conversation, or not? If not, consider safer options like crypto_secretbox_xsalsa20poly1305 with random nonces—or maybe a deterministic authenticated cipher, which can't conceal the fact of message repetitions but otherwise survives nonce reuse.