By and large I agree with Juanjo's statement of principles, but I would like to discuss the reason /why/ ASDF is different from tools like Autoconf.
Lisp development --- at least for people like me --- is primarily an interactive process, and this is why building and loading/executing are /inextricably/ linked.
It is, IMO, /not/ a handicap that ASDF performs both building and loading tasks, because Lisp software is not like conventional software.
In particular, this apparent duality ceases to become a source of confusion/dismay, if one stops thinking of "building" and "loading" and thinks instead about maintaining the integrity of a running lisp image.
Building and loading are just pieces of that integrity maintenance process.
I am with Juanjo in wanting to see the process of integrity maintenance become more declarative, and less cluttered with arbitrary procedural code. But I don't think that decoupling building and loading is particularly desirable in general.
For an extreme perspective on this issue, I'd encourage interested readers to look at Drew McDermott's paper on his integrity maintenance approach based on arbitrary chunks of code (a finer granularity than source files), where, for example, one can define dependencies needed to compose a hash table, so that its correctness (integrity) can be restored when data structures on which it depends are mutated:
http://cs-www.cs.yale.edu/homes/dvm/papers/lisp05.pdf
This is admittedly an extreme, but it shows a purpose that systems like ASDF can serve --- maintaining the integrity of a running lisp image over extremely long periods of time.
Autoconf and make are not the tools for people who want to be able to keep their lisp sessions running for days, weeks, or even months at a time. To do that one must integrate building and loading.
To borrow an analogy from Mikel Evins, the lisp session is a world that one creates, and which one can occupy. In this way it is radically different from building software in C, for example.
Best, r