Most compression algorithms have a limited data reference window (dictionary size) - tens to hundreds of MB being typical upper limits. If duplicated data is further apart, it gets compressed again.

If the data isn't pre-compressed, or doesn't otherwise significantly vary, then using the right tools should de-duplicate the data. Things like lrzip, rsync batch mode, bdiff should work well. If large blocks are identical, many filesystem archivers/backup solutions should do good deduplication, and squashfs can be kind of nice.

That MIGHT be happening, honestly not sure.

There are possibly challenges in that however, my understanding of most compression algos (which may be inaccurate or incorrect) is that you'd run into limitations either with size of data overall or the memory requirements.

Of course, I'm sure there's other ways around that (And I have no clue if they are in use). One option would be to send over the assets in a master 'assets' package and then duplicate/assemble the data as intended during installation.

That's not how compression would work. Think about if they are adding a new level. The algorithm would have nothing to compare the files against except what is actually being sent. If the texture appears in each level, and each level comes in a separate update, there's no way for the algorithm to reference or incorporate the files that are already in your computer, so it has to compress it like it's a brand new file. That is unless you have a costume installer which duplicates the file once it runs, but that would probably be a ton more work for the developers.