This is programming, so I don't _feel_ as much as I decide based on rational arguments. Here, it is simple:
in the case where `var d;` is on a separate line, any programmer arriving at this line thinks “mmm… what purpose would `d` serve? I hope it's not an unused variable”. Then at least some programmers (for instance, those who are coming from another line) think when they arrive at `d = createDeferred()` “mmm… where would `d` be declared? I hope has not been not forgotten.”. Placing the declaration on the line where you actually use the thing saves us a line and a semicolon, and avoids two questions that might arise. That's a matter of efficiency and thus easier maintenance. Remember: code is read more often than written.
Having recently studied the _Good parts_ book, I understand Crockford's reasoning: he's presenting a subset of JavaScript that makes certain kinds of mistakes less likely. Hoisting is indeed one of those things that can be tricky.
However, I am confident that I understand hoisting, and also, I have my own policy (enforced by jshint) to never use a variable before it has been declared, so I never run into strange hoisting issues. I'm sure that I can handle the full set of JavaScript, and I see hoisting as a feature, nog a bug. Indeed: I don't _have_ to write the variable at the beginning of the function in which it appears, because JavaScript will do that for me anyway. So I might as well use it in the place where it is actually used, to avoid spreading information around.
That said, I though about the pro and contra arguments sufficiently to say that here, the combined declaration/initialization is the option that leads to the least confusion and the best possible maintainability.

I think your comparison to `eval` is unfair. `eval` feels indeed wrong, also to me, because it introduces the danger of unsafe code, is not optimal for engines such as V8, and is often a sign of an inferior solution as there are almost always more elegant options that avoid `eval`. Therefore, `eval` is bad for robustness. Similarly, I feel an `onclick` attribute feels wrong because of the rational reason that it mixes markup with behavior, which is bad for clarity and maintainability. And for the record, I do eat rice with a spoon, because I spill more if I eat it with a fork (also a case of efficiency).
So it's not a matter of feeling, but a matter of rational thought. The only error one can make in programming style is obliviousness; if only you're aware of the implications of using or not using a principle, you can make an optimal decision.

PS This rant is by no means meant as picking on your comments, which I really appreciate. I just want to make my viewpoint on style clear, as I do care a lot about it (see: [Programming is an Art](http://ruben.verborgh.org/blog/2013/02/21/programming-is-an-art/)).