"Bad" typography isn't a big deal IMO. Yes, it's slightly embarrassing and ugly, in this Unicode-enabled era, that we use <= for "less than or equal to" and != for "not equal to", when Unicode has given us better glyphs. But honestly, I don't see how that costs us much time to get used to. It's like the parentheses in Lisp: more time is spent complaining about things like that than just adapting to it and making the problem go away. Parentheses wouldn't even crack the Top 5 of my complaints about Clojure (which is, despite some flaws, a great language).
Regarding monospace fonts, monospace is a huge asset. Sometimes you want to align a column of numbers, and you don't want 11111 to be narrower than 8888. Code isn't supposed to be "pretty" in the sense as a word document or marked-up Latex file. It's supposed to be easy to read and understand. Aesthetics are a part of this, but beauty at the expense of clarity is a no-go. Technical book writers could easily use non-monospace fonts for code examples and they don't-- for good reasons.
What matters is how the language looks after you've been using it for months. After 6 months using it, does the language still piss you off on a regular basis (note: no language is perfect and all will piss you off sometimes) or do you generally enjoy working in it? I've found that statically typed functional languages (Scala, Ocaml, Haskell) perform the best in this regard. The worst I've seen are Java and C++. But until you get comfortable with the languages, they all look the same (hideous, confusing, foreign).
We need to get rid of that kind of thinking—not just so that language design can move forward, but so that we can quit worrying about languages and get shit done.
Sorry, but... language differences aren't really about superficial appearances. Ocaml could be re-written with S-expression syntax and it wouldn't be much different. These differences are much deeper than that. The shape of code that emerges in a Haskell codebase is dramatically different (more "foreign" compared to conventional imperative programming, but generally less verbose and easier to maintain) from what appears in a C++ or Java codebase.