Eh, I'm not sure I would agree, about the 6502 specifically. It's a pretty bad match to C since e.g. it doesn't have a relocatable stack and common pointer-based operations are quite clunky despite the provision for several address modes. FORTRAN-like languages really do match quite a bit better. In a different way, so does FORTH.
Also, plenty of people did have fun writing assembly code for the MC68k, which is a 32-bit CISC architecture. It's really only x86 (and maybe VAX) that tends to be a bit clunkier.
Personally if I'm going to have fun writing assembly for a project like this, I'm not too picky about the particular architecture.
Newer experimental 6502 languages either forbid recursion (cowgol) or limit parameters passed to functions (C02), but I can see a language using a hybrid of stack and zero page to keep locals and parameters.
The drawback of high-level programming on the 6502 is you are always looking for ways to make it better... :)
So for 6502 I would rather not be writing C.
Check out PLASMA. That is being used to develop the game lawless legends. It's pretty damn impressive.
With the 128KB +3A model you could use CP/M, which had a better compiler available, still a pseudo C toy compiler versus the real thing on UNIX.
We only used such compilers for homework assignments.
(No, I never worked on such a system... but my mother did.)
Also, some of the newer ones have small amounts of nonvolatile FRAM instead of separate SRAM and Flash banks.
I guess each to their own though.
You can really do this on any modern platform as well. It just takes a bit of effort. Understanding performance characteristics can be an order of magnitude harder, though.
That said, I understand the allure of trying to work 'native', and it's a mistake/trap I often fall into myself.
Anyway, for the C64 many of your "APIs" -- especially for games -- are accessed by peeking and poking memory-mapped locations, careful usage of the zero-page, etc. C doesn't help you with that stuff but assembly loves it.
If you aren't in there counting cycles you are leaving so much on the table, and there just isn't that much table!
The book for it was very nice as well. Best bang for the buck at the time. Could only compile code up to x286, not 386 CPUs
(the ALL CAPS code example with some really horrific variable and function names is a nice touch of the 80s)