Well, maybe; how do HTTP/2 servers allocate bandwidth? If they do it per-stream, you can still identify the size of each package by watching the total connection bandwidth decrease when each package ends.
If they allocate it for the whole connection, then all they get is a total, which still gives the attacker some information (there's a limited combination of packages that sum up to that number).
You are assuming, that all packages are equally interesting (and your math does not account for package dependencies).
In practice, attacker either does not care about your packages, in which case hiding that information gains you nothing, or wants to be alerted, when you (or anybody else) install one of few specific packages. Those combinations can be computed in advance and identified in traffic.
Not necessarily, I think you underestimate the complexity of this attack.
Even if you were interested in a few packages, if any additional packages are mixed in or if dependencies are already installed, this problems become a lot harder again.
While HTTPS doesn't make such an "attack" impossible, it makes it very hard and compared to HTTP the attacker cannot inject or replace data (replay attacks are possible with APT on plain HTTP)
If they allocate it for the whole connection, then all they get is a total, which still gives the attacker some information (there's a limited combination of packages that sum up to that number).