I decided against pursuing GBA homebrew in particular, though, because Nintendo DS homebrew is slightly more fun while not being particularly higher-level than the GBA. You've still got sprites and backgrounds and scale/rot/shear effects; but now you've got two GPUs (where either GPU can address either screen), and a 3D layer sandwiched in amongst the background layers and sprite layers.
† Though, I mean, that's a matter of interpretation; all the modern 3DS and Wii U homebrew is still released/discussed/developed on the GBATemp forums, which—obviously—had its roots in the GBA homebrew scene.)
At least, this seems like a sane approach to me. It benefits from less of the existing reverse engineering work on NVidia chipsets, BUT it's higher level, which probably means it will be easier to understand and yield better performance in practice, especially since it is going to have to be implemented on top of higher level GPU APIs anyways.
You could write the entire opcode table for an ARMv7 chip and run ARMv3, ARMv4, etc code on it. Assuming there aren't any illegal instructions and that you've got the timing right, it should run just fine. So, essentially, you've got 1/3 the hard part done.
The GPU for the GBA was basically a chimera of the GB engine and the SNES's. Even had similar modes built into the BIOS. The Switch has a Maxwell based GPU. One very similar to that in the Tegra X1, which is very well documented (If you're willing to dig through their massive Technical Reference Manual (https://developer.nvidia.com/embedded/downloads) and the nouveau source.
That just leaves audio, the bus, game formats, etc to be "discovered" or reverse engineered.