This is one of the most widespread misconceptions about compilers. You don't need to build an AST. All books that give this advice originate from academic environment and are completely out of touch with reality. Unfortunately these books can be credited for the terribly bloated compilers that we are using, including Python and Perl.
Can you give an example of an Open Source (so we can learn how it is done) compiler that embodies an alternate strategy?
Turbo Pascal - probably the smallest and the fastest commercial compiler ever made - well, for an imperative language - was inspired by Wirth's book, too (see http://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures_... )
"The entire fifth chapter of the first Edition has been omitted. It was felt that the subject of compiler construction was somewhat isolated from the preceding chapters and would rather merit a more extensive treatment in its own volume. "
Ur-Scheme (http://canonical.org/~kragen/sw/urscheme/) doesn't have any intermediate representation other than the S-expression representation of the code; it uses that to perform closure analysis. Probably an AST is the easiest form to perform this on. The Lua guys came up with an implementation technique for closures that doesn't require building a parse tree first, but it's quite a bit more complicated.
We can look at specific examples if you wish.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.27.3...
> We can look at specific examples if you wish.
Common Subexpression Elimination, for example. Not just syntactically equal expressions but also cases like this:
a1 = b + c
a2 = c + b // eliminated
Edit: I now realise that we may be talking about different abstract syntax trees. I thought that you meant no intermediate data structures. But you probably meant that you don't need a parse tree, you can translate to the intermediate language directly from the source. If that's the case then here's another challenge: how do you produce error messages for type errors?