The 65816 is a better target (moveable direct page and stack and some wider registers), but also awkward with its register mode switching.
Doing something like "JMP ($2345)" will jump to whatever $2345/$2346 is pointing to.
But only a little. I didn't have the money to buy an assembler or the skill to write one so I would write out my programs in long-hand on graph paper and hand-assemble them before entering hex codes manually. While not the most efficient process, it did do a good job of encoding things into long-term memory.
In the meantime I've forgotten most of the 68000 and z80 instruction sets.
My second (and last) assembly language after 6502 was 370 which replaces the "awkward immovable stack" of the 6502 with no hardware stack at all. Applications are completely responsible for maintaining their own call stack.
If all your functions are void foo(void) and you don’t use local variables (or your language doesn’t support recursion, in which case all locals can be given a fixed address), targeting 6502 is fine (it also helps if you avoid floating point, use 8-bit variables where possible, etc)
Not supporting recursion also means you can statically compute maximum stack depth. That way, you can avoid linking code that would overflow the stack.
I recall a tutorial for 'cc65 optimizations'[0] which basically destroys a well-structured C program in order to do all of these optimizations (like making everything global) and it was absolutely terrible, code-wise. Well, the end result was probably fine, but it's just a shame these 'optimizations' were needed.
[0] I think it was this one: https://github.com/ilmenit/CC65-Advanced-Optimizations
Some nice simple extensions to the 02 architecture would be:
1) relocatable direct page and stack like in the 816. 2) some way of aliasing A to a direct page address to avoid doing it by hand.
A main advantage of the 6502 is that it only has 64 kilobytes of memory ;-). That means sufficiently advanced and motivated programmers can keep the entire program in their head, and also nudges them to avoid bloat such as the use of 16-bit integers.
You'd need a little region for making use of (zp),Y, probably callee-saved, putting previous values on the return stack with PHA.
I suspect that an LLVM backend for the 816 would have to be something quite a bit different from the 02.
I personally would choose the 65x816 over the other for a new design, but I can understand why it’s not as popular.
[0]: 40 was the de facto maximum. Although, the M68k had 64. That thing was a monster in size.