I get the sense that these disassembly/decompilation projects believe that some types of IP-laden asset data can be shipped embedded into the project — not necessarily "legally", but in that they'll likely get away with doing so indefinitely — as long as:
1. those assets are stored in proprietary formats that only the game code itself understands, and
2. no tool exists in the project to extract the assets from these proprietary formats into open formats, unless that tool itself exists only in source-code form in the codebase, and requires the ROM as an input to compile it (even if in the case of such a tool, the ROM is doing nothing but serving as a "key" to unlock compilation.)
Basically, if you have to prove you have a copy of the IP in order to make their embedded copy of the IP "legible", then it's very hard to construct an evidence-based DMCA takedown order that actually makes any coherent point about the project "distributing" said IP.
That being said, shipping assets like this at all, even if you "can get away with it", is ultimately just a kind of laziness / shortcut-taking. They do it because there's no simple/obvious way to store a particular kind of extracted asset data where a regular compiler/assembler natively knows how to embed it in the particular way it was found in the original ROM.
But what they should actually be doing, is writing codegen tooling, that runs before compile/assemble time, and converts the extracted ROM asset data into the form you currently see it in in the repo. For example, by taking animations that were stored in the ROM "exploded" across various banks, and which get extracted out as spritesheet images, and splitting+transforming the chunks from those images back out into generated "per-aspect" assembly files filed into the appropriate original code banks.
