Well, its not really.

That is, I agree that compression would usually improve if we just replace any simple counters (like frequency-based or linear) with paq counters.

But similarly we'd be able to build some bit history submodels with linear counters and mixers/SSE (maybe static) which would be significantly better than paq counters as such a replacement.

In fact, even a single "delayed counter" is enough to beat the paq's counterpart. ("delayed counter" is a counter which keeps the recent bits in a small buffer and is updated with the oldest bit from the buffer... using other bits as a context for update parameter selection).

So, for the best effect, we need to build the most efficient context history model with small enough variable state (up to 24 bits? its full probability mapping has to fit in memory), but maximum usable static elements, and then cluster the states so that the quantized state would fit into required size (1-2 bytes I guess), then build a state-to-probability mapping table and a state transition table for updates.

Its also quite important to be able to do this table generation fast enough so that it could be included into a compressor, as that would allow for parameter tuning.

Now, runtime parameter tuning is unavailable for paq counters, also paq counter generator (stategen) does quanization by probability (which is far from perfect), and imho a single byte is not enough to represent a context anyway.

In other words, a counter is a lossily compressed version of context history.
Thus in no way its possible to have a single universal counter for all applications.
Well, not until we'd have a universal lossless compressor :)