How could block encryption in counter mode be secure from viewpoint of entropy? A good block cipher e.g. AES running in counter mode is commonly considered to be secure. Assuming a perfectly random key, one could in this case from $128$ bits generate up to $2^{128}·128$ bits for stream encryption.

However, these bits could evidently have only $1/(2^{128})$ bit of entropy each on the average. Isn't it a paradox that such an encryption could nonetheless be secure?
Summary: an entropy argument shows that block encryption in counter mode can't be perfectly secure.

The remark that any block cipher in CTR mode generates a keystream with very low entropy per bit of keystream is correct. That hints CTR mode is not secure against an hypothetical unbounded adversary. In fact that holds as soon as more bits of keystream are used than there are in the key (or sooner): that unbounded adversary could enumerate all the possible keys, and rule out some keystreams as impossible.

This does not contradict that AES128 is practically safe in most but not all situations, against a real bounded adversary.

As an example of why I write "most but not all situations", consider the feasible case where an exbibyte of data (a fraction of a day's worth of global internet traffic) is enciphered with AES-128 in CTR mode; that's $2^{56}$ blocks, and odds that two ciphertext blocks are exactly identical are a low but sizable $2^{-17}$; should that occur, an hypothetical adversary able to detect and locate that equality (which is much more difficult than the encryption itself, but might still be feasible) would have learnt one tiny bit of information about the corresponding plaintext blocks: they can't be exactly identical; and thus, assuming an all-zero plaintext was characteristic of non-activitly, the adversary would have learnt that there has been activity in at least one of the two spots where the equality is detected.