I think that’s misleading.

Not having a comprehensive stack trace is much more painful for imperative or especially OO code, where the state at the time of failure is practically impossible to discern.

Erlang gets away with it (for decidedly non-trivial production code like much of the world’s cellular routing) because state is much easier to determine.

(Or maybe I’m blowing smoke. Certainly that’s how it feels to me.)

Safari/JScore, the only browser to implement TCO solved this using shadow stacks.

TCO -> I see your point about stack tracing and tend to agree, but more importantly, one key difference between Javascript and Scheme is the focus on recursion. Javascript decided that imperative looping was the proper, idiomatic way to handle iterative expression construction. With this design decision, leaving aside whether the looping vs recursion is an equal trade, TCO was not going to be a priority and the style of programming grew around that first choice or iterative style.

Hygienic Macros - I love macros. However, in contrast to your position, I like my macros like I like my martinis... clean, as a general rule. So while I like a basic assumption of hygienic macros I also want the capability to produce ugly dirty procedural macros to be available. But that is just a preference of mine. I agree that the wealth of options for automated and principled syntax tree manipulation and code generation makes the need for built in macros almost non-existent.

Continuations -> while I understand the strong warning, drifted continuations enable some very nice coding possibilities, particularly implementations of generators, coroutines generally, and better callback syntax. Javascript just decided that instead of handing devs the keys to the Delorean they would just chauffeur everyone, i.e. they built constructs for these common and useful patterns directly into the language semantics. This is particularly the case for future based coroutines, now with the async/await sugar.

I have debugged poorly written defmacros for longer time than I spent fighting macro hygiene. I implemented defmacro using syntax rules (about 7 lines of code if you have access to schemes with optional and keyword arguments) and use it frequently. My rule is however that if I ever want to introduce bindings of any kind I will use defmacro. Simple. Saves me a lot of pain. But when it comes to macros there is no truth. This discussion has been going on long enough for most o us to know that it is a matter of taste.

Call/cc is overkill. It is a shitty, leaky abstraction that nobody really wants. Delimited continuations are the bee's knees! They compose, capture just the things you tell it to and are fast. They follow the idea of having a well chosen set of primitives as building blocks. You want CL's tagbody? No problem. Fast coroutine style generators? You got it. Cooperative, fiber based multitasking? Just a pure scheme library waiting to be used!