Your very first example is a poster child for everything WRONG with modern JS development, as you've added the overhead of a function to the code, resulting in a painfully inefficient execution and distribution over just using a comment. ESPECIALLY if this were to be used as client-side code.
In that case, a comment "// are they eligible for child care benefits" would be many, MANY times more efficient and effective. Why?
Because it’s code that DOESN'T execute. Because if you minify for client side it will be removed resulting in smaller code. Because you don't have to go hunting for wherever that function ends up in the final code when editing. Because the interpreter doesn’t have to search the namespace for that function. Because you don't have the painfully cryptic and obtuse arrow function crap in it. Because those nonsensical worries about scope that "let" and "const" are allegedly there to "fix" become a non-issue.
EVERY time you introduce a "function for nothing" regardless of programming language, you're adding a lot of overhead. In compiled languages that works out to this assembly in most cases.
.subFunction:
PUSHA
MOV BP, SP
; do what the function is trying to do
; assuming 64 bit return address and
; stack grows towards data selector
; parameter offset == BP +8
; parameter selector == BP + 16
POPA
RET 16 ; 16 is size of selector and offset.callingArea:
PUSH EDS ; push parameter selector
PUSH EAX ; push parameter offset
CALL .subFunction
The above being AMD64/EMT64/x64/pickANameAlready code. ARM it's many times WORSE. (since RISC's orthagonal layout results in more code!)
In an interpreted language like JavaScript it's many, MANY times more complex than that, with objects (which all functions in JS are) making it even MORE complicated with the shift in stack frame and heap allocations.
One of the worst things you can do in an Interpreted language like JavaScript is introduce functions you don't need, and it’s why this current hot and trendy use of const functions, arrow functions, and callbacks is mind-numbingly dumbass. You say “comments can’t make up for bad code”, I would say the inverse is also true. Adding bad code isn’t a solution when good commenting can do the job.
…and it's why as someone else I saw a while back joke "This is why Hello World is 32 megabytes now"
That said, the rest of your explanations make sense, it's just that example that's a crate-load of "NO!". Don’t use code that has to be executed to do what can be handled by a comment!
There's an older article on the topic of commenting and code clarity I always point people at on IBM's Linux developer site. It's written from a C perspective but the concepts apply across all languages.