Because you'd need not just one, but many of them, in order to keep things simple and manageable - for the philosophical background on this read about the Nanopass approach: http://www.cs.indiana.edu/~dyb/pubs/nano-jfp.pdf
> Build a straightforward AST then convert to LLVM.
It's only possible for the very low level languages without any interesting features.
Firstly, you'd need some type system, even if it's mostly dynamic. Secondly, your frontend may provide quite a bit of syntax sugar that will need further lowering before you can easily turn it into IR.
Even before typing, you'd have to handle the lexical scoping, which may also involve an additional intermediate representation (one distinct IR per each pass is normal).
With this approach you can keep your entire compiler pipeline as a sequence of trivial, fully declarative, pattern-based tree rewrites. With the less fine-grained approaches you'd end up with a barely maintainable mess, where multiple passes functionality is combined into a single bloated, twisted pass.
> Semantics is important.
Of course it's the only thing that is important. Unlike syntax.
> Build a straightforward AST then convert to LLVM.
How well do you think LLVM is going to optimise that code? You can't just give LLVM dumb IR directly generated from your AST and expect it to somehow work magic.
LLVM is low level. You need to lower your high level operations, such as method dispatch and metaprogramming, a long long way before LLVM will do anything sensible with optimising it.
For example Rubinius generates LLVM IR directly from bytecode for Ruby (so it's even a level more sophisticated than you suggest), and for every benchmark I run it's basically no faster than MRI!
For another historical example see Unladen Swallow.
Semantics is important. Before you start writing the frontend, I would advise to write some programs in your language like a tutorial for newbies.