Yes, if you're willing to invite all of the challenges associated with dynamic recompilers, like dealing with self-modifying code and branches.
Â
When you just want a one to one correspondence you can use a direct mapped decode cache. This is what the author of Gemulator likes to do (see emulators.com). This makes it so you don't have to perform and block tracking and mapping, but you still have to invalidate cache lines on writes to accommodate self-modifying code.
Â
In this case, it's actually just as well to just use a lookup table to convert any Thumb opcode to an ARM equivalent (or special undefined ARM code where there's no equivalent). The input is only 16 bits, and the output is nominally 32 bits. You'll likely need another bit of output, though, to determine how whether the PC offsets should be halfword aligned or not, because Thumb behavior regarding this is inconsistent. This method would probably be superior to any kind of cached conversion.
Â
For your purposes, that is, only using interpreters, eliminating code is really the only benefit. Performance would be substantially worse because of the time needed to convert from Thumb to ARM, and also because ARM instructions are just a lot more expensive to emulate in general. In a usual GBA game over half the instructions executed will be Thumb, so you'd be hurting speed a ton across the board.
Â
I went with this technique in the emulator I'm currently writing, but only because I was never planning on relying on the interpreter for speed (did a recompiler for that) and I wanted to have less points of failure. For recompilation, where the speed isn't that big of a deal, it's nice to have less code to work with, and having one instruction set instead of two means you don't have to write a bunch of analysis and optimization code twice. Another benefit is that it gives you room to perform propagation from Thumb to ARM, resulting in ultimately better code.
Â
So in short, I think you shouldn't do it.