There's a principle called "Cognitive Load Theory" [1] which I believe all teachers have to take seriously. Specifically, the "extraneous cognitive load". It's why I choose to introduce concepts with foo/bar style first.
I am concerned by the observations I've made over many years of teaching (JS) that many people tend to get distracted by problem domains and miss out on the underlying concepts. For example, if I am teaching about `this` but I use an example like a login system, it's far too easy for someone to get distracted by what they know -- or worse, what they don't know -- about how login systems work.
It's an overload on the cognitive side because the learner (reader) is having to juggle not only the new concepts but also their knowledge/opinions/baggage about the problem domain.
Cognitive overload is so "dangerous" not just because you might overflow someone's capacity and they stop getting anything out of the teaching, but because it has the tendency to become subtractive and actually cause them to lose what they already knew or had learned about the concept.
So... my approach in teaching, which is also reflected in the books, is to default to teaching a concept first without a problem domain, using generics like foo/bar, and THEN once I feel someone has the concepts, later, you can reinforce those with practical applications in problem domains.
IOW, I'd teach the abstract principles of `this` first, then the abstract principles of the Prototype system, then I'd start to show some examples like a login system that show how you can put those abstract concepts together into a real thing.
Anyway, I understand it doesn't meet your preference, but I just wanted to explain the reasoning behind it from my side.
When it comes to "foo bar" examples, as a learner, I think it causes MORE cognitive load not less.
I think this is because, it's hard to make connections between meaningless words like foo, bar and baz
Conversely, most of the "aha" moments come from your ELI5-like explanations of concepts
The concept of a "promise" made sense to me when you used buying a hamburger at a fast food store in your workshop on asynchronous javascript.
It's like -- 'a human without makeup is the most real'
The variables are all `foo`, `bar`, `baz`, `a`, `obj`, etc. And the values are all just numbers. Sometimes they have a function that takes a value `a`, and they just do `this.a = a`. It requires a ton of cognitive strain to glean out what they're trying to show you in the examples because of this.
IMO the best books are those where they use silly (possibly contrived) "sample program" that the examples all build on. I mean, you could make your classes Cows and Animals, your functions moo's, your properties things like name and favoriteColor, and things can suddenly be a lot more readable when you want to do something like show lexical scoping rules. ("Oh no, that cow's name is steve, when you may have expected it to be bob because of the difference in what `this` refers to" is a lot easier in my mind than a big see of `foo`'s and `bar`'s.) Or maybe an example involving a bank and deposits and withdrawals.
It seems like a minor nitpick but it's things like these that I really use to judge whether a book is actually of good quality. I mean sure, any half-decent programming book exposes you the concepts that make you a better developer, but the good ones do so in a manner that makes it easy to understand.