I'd imagine bsnes is somewhere between interpretation and dynamic recompilation.
Static recompilation would be really difficult on systems like the SNES and GBA, which have two processor modes (8bit 6502 emulation/16bit 65816, and 16bit THUMB/32bit ARM respectively), so the width of any given instruction is dependent on the processor state. Dynamic recompilation would be faster than instruction-by-instruction interpretation, but full dynamic recompilation (with subroutine caching and all) would probably get pretty difficult to time (I could be wrong), and cycle accurate timing is a stated goal for bsnes (to the point where byuu had the enhancement chips like the CX4 decapped).
bsnes has taken the low-level route because a decent bit of the software for the SNES is really timing sensitive - even that black circle effect at the end of the level in Super Mario World is done by changing values between scanlines. For systems like N64 on the other hand, where the software is less timing sensitive, high level emulation techniques are more common, for the sake of speed increases.
As best I understand it, bsnes is purely a bytecode interpreter. It does fancy tricks with stack-swizzling to quickly switch between different parts of the code to get the timing right, but it never ever generates instructions for the host CPU architecture.
Actually, I think it's more accurate to say that (at least for the 65816 core), that bsnes is a pipeline interpreter.
Each 65816 opcode takes between 2 and 8 cycles to execute (more for the MVN and MVP opcodes) and there are rules about when interrupts can be asserted -- bsnes correctly emulates these processor details.
Also, I believe the bsnes properly takes into account the read and write states of the memory bus. This is also an intra-opcode level of detail.
AFAIK, some of the other CPU cores (esp. the DSP-n and Supergameboy cores) are straightforward opcode interpreters.
