I guess to figure this out you have to figure out what changes with the entry point when a regular DS reads a TWL game.
To me it sounds like the game is checking against the hardware it's running (or rather the operating environment). Like at boot the ROM runs a system call to the underlying firmware that only a DSi can respond to. If the underlying firmware doesn't return the expected value then it boots past any DSi code that it would call otherwise. .NET Framework apparently does something like this to verify if the CPU it's running on has SSE2 instruction capability (certainly not the only example that could ever exist but the one I know of, thanks to the work MattKC did to backport .NET Framework 2.0 to Windows 95). A more mainstream example might be how Shantae differentiates between a Game Boy Color and a Game Boy Advance (the console doesn't know the game it's playing is a GBC ROM that has GBA enhancements, it's up to the game to know it can access resources exclusive to the GBA). Non-DSi Enhanced games don't care about identifying the underlying hardware so they go straight to calling the main function in the executable.
If Nintendo didn't write the DS emulator in the Wii U to have a state that accounts for this (only needing to address it if they ever released a DSi Enhanced game on the platform - even if the emulator wouldn't support DSi enhancement capability - which never came) then when the ROM boots it's trying to call a segment of the emulator that doesn't even exist and crashes the emulator. I see Robz said they replaced the ARM7 binary with a non-DSi Enhanced game so I would assume that means changing the entry point to one that would never attempt to interact with any DSi firmware. Since that failed I would presume at that point the game code itself is relying on hearing back from whatever function that would or would not initiate DSi functionality (so maybe the emulator doesn't crash but then the game hangs because the executable can't move to the next stage of booting, waiting for a response from a function that was never called). A non-DSi executable wouldn't be able to call whatever the DSi Enhanced ROM is waiting for to start running as a standard DS game.
Therefore the ROM would have to be patched to be packaged with an integrated launcher that intercepts the system call to the firmware, returns a static value that tells the ROM it's running on a standard DS, then ignores any further code that would be related determining the hardware type and advancing straight to booting as a standard DS game. It wouldn't be as simple as erasing a header or swapping an executable because they're all tied together as part of the booting process (firmware launches a DSi Enhanced game > DSi Enhanced binary makes a function call back to the firmware to figure out the environment it was launched in > firmware responds with something that sets a flag back in the binary to tell it what system features it can request > binary calls next stage of the loading process in the game code itself based on the state that was determined from the previous stage). If you're lucky Nintendo standardized this sequence into their devkits so every game with DSi Enhanced capabiltiies uses the same process to determine its operating environment.
I don't follow the DS emulation scene much (since I just run DS games on real hardware either with a flash cart or via TWiLight Menu++ in a 3DS) but if any emulators out there have something like a memory reader that lets you see what's happening in RAM as a DSi Enhanced game loads you could tease out the code that flips on this functionality then potentially write something into the VC injection process that hex patches this process to always return the same state every time if a DSi Enhanced ROM is identified during the injection process (or, failing that, a standalone patcher that would apply said fix to a raw DSi Enhanced ROM prior to injecting it). I would imagine being able to comprehend this would require a fair bit of low-level code understanding, though.
EDIT: I think the first step to truly unpacking this and potentially identifying the root cause would be to see if you can get a DSi Enhanced game to boot as a DS game on a DSi by fudging around with the ROM. Can you make the DSi somehow ignore that it's running a game that can make use of its expanded hardware and run the game as it would on a regular DS? Doing that would help identify which part of the loading process turns the game into a DSi Enhanced title, based on whatever you modified to get it to behave in that way (it wouldn't solve the problem in itself, since you'd then have to see if it's possible to spoof this process on the software side when you inject to the Wii U, but it would tell you whether or not the hardware or the game is flipping the switch to go from standard DS to DSi Enhanced).
