I've implemented Atari 2600 library support for both LLVM-MOS and CC65, but there are too many compromises to make it suitable for writing a game.
The lack of RAM is a major factor; stack usage must be kept to a minimum and you can forget any kind of heap. RAM can be extended with a special mapper, but due to the lack of a R/W pin on the cartridge, reads and writes use different address ranges, and C does not handle this without a hacky macro solution.
Not to mention the timing constraints with 2600 display kernels and page-crossing limitations, bank switching, inefficient pointer chasing, etc. etc. My intuition is you'd need a SMT solver to write a language that compiles for this system without needing inline assembly.
A very simple BASIC compiled pretty well! It did feature online assembly, and I agree with you on this necessary point especially concerning the 2600!
See Batari Basic
This is the kind of argument that makes people come up with middle manager stereotypes in the first place. In fact, the whole post is a great example of why middle manager stereotypes exist: it starts with a straw man argument and comes up with a "better alternative" that makes life easier for the manager, regardless of what the manager's reports really need.
I've seen this whole "I will empower you to do everything on your own" principle in action and it's exhausting. Especially when the word "empower" is a used as a euphemism for "have you take on additional responsibilities".
Look, boss, sometimes empowering me is just what I need, but sometimes I need you to solve a specific problem for me, so I can keep solving all the other problems I already have on my plate.
I(we) call that running interference, and it has always been an extremely high value activity. The people who see the benefit rarely complain. I myself have always recognized it as valuable.