My viewpoint is that HTML shouldn't be written directly, because the language isn't designed to be particularly DRY. Isn't that very much at odds with Enlive?
Enlive does exactly what Hiccup does with the additional bonus that it allows designers who are comfortable with HTML to be a part of the process. Enlive is not page centric - that's the whole point of snippets.
But if none of your designers are writing HTML, what benefit does Enlive have over Hiccup? Whilst Enlive could probably mimic Hiccup's style through aggressive use of snippets, it seems to me that it would need more code to produce the same result. Enlive seems the wrong tool for the job if you want to use it in the same fashion as Hiccup.
Enlive vs Hiccup seems entirely dependent on the composition of your group. For a group of programmers, Hiccup is an efficient means of not repeating yourself. Add a single designer and you'll find programmers implementing a lot of mockup images to be compatible with IE7. Try hiring more designers, especially ones who can use existing design tools, and you'll find Hiccup-style to be completely unusable. Enlive-style allows a company to hire designers who can produce HTML that works in all the browsers that you support, leaving programmers to work on functionality.
For the record, I think Enlive is incredibly useful for a large number of teams.
However, I'm a HTML purist at heart. I believe HTML should be semantic markup, and that the page design should be independent of the HTML generated, whenever possible. Ideally, it's the CSS that should determine the page layout and style.
I also work for a company that produces very uniform web interfaces, and where the developers significantly outnumber the UX guys. Hiccup would work very well in this environment, but perhaps not so well in an environment with many designers :)
