to read or debug code with them in it one
has to understand them
I think what the author is looking for is better compile-time checking and error reporting in the the with-* macros. I'm not sure how to respond to the "understanding" points. Is the need to understand your language constructs considered a sign of leakiness? I would say no.
When I run a program I've written in C or Python, the only program that's really running is written in x64 machine code, because that's the only language the processor understands. But I can debug my program without having to understand the x86 instruction set, because high level languages abstract it out.
But if the abstraction was leaky, OTOH, I would still have to understand the details of what's being purportedly abstracted out, so the abstraction wouldn't be properly doing the job of an abstraction.
That's why leaky abstractions are a bad thing.
It would seem "understanding" might be the wrong word. If I were to write something like:
(+ 'foo 1)
(with-open [foo some-object-that-isnt-a-stream]
...do stuff...)
If I have to know the details of the expansion of a macro in order to use it correctly, then it is almost by definition leaky.
In the case of "with-open," a simple type check at the beginning of the macro expansion would solve the problem.
The exception that's thrown in your first example above certainly makes it blatantly obvious what you did wrong, which is nice. but you still have to know that the addition operator doesn't let you concatenate numbers and symbols in order to use it effectively, or your program will crash once you run it. That's on you.
Granted, laziness still makes this issue very, very tricky.