The flaw they're pointing out is that 7z's AES encryptor has a 64-bit IV (half the block size) --- not itself a vulnerability in block ciphers --- and uses a predictable RNG to generate the IV (for simplicity, just call it "time and pid"). 7z uses AES in CBC mode.
In CBC, you want IVs to be unpredictable; if you can predict an IV and you control some of the plaintext, you can in some cases make predictions about secret data that follows your controlled plaintext (this is an "adaptive chosen plaintext" attack).
This doesn't really come up in 7z's usage model; you're supposing someone integrates 7z with their own application, which, on-demand, encrypts attacker-controlled data with a secret suffix and puts it somewhere the same attacker can see the resulting ciphertext. Don't do this. In fact, if you're using ZIP archives in your application, don't use ZIP's AES at all; encrypt yourself with a modern mode. ZIP AES isn't meaningfully authenticated.
Having said all that: for the normal usage of an encrypted ZIP, this doesn't really matter at all.
It's a good finding, though! Cheers to anyone who takes the time to look at the underlying code for any popular cryptography. I hope they keep it up.
A more important PSA: unless you're absolutely sure otherwise, you should always assume any ZIP program you're using doesn't actually encrypt password-protected ZIPs. It's just as likely that it's using the old, broken PKWARE cipher, which is dispiritingly common due to backwards-compat concerns. It would be nice if there was a mainstream, built-in way to password-protect a file that you could share with someone else (or just stick on a thumb drive), but ZIP encryption isn't it.
Pentesters sometimes go out of their way to use 7z because it actually does encrypt with a real cipher. And, I guess for what we're doing with it, 7z is fine. But it's sad that it's the best common denominator we have.