Thoughts on the "Software craftsmanship" movement

On the face of them, the ideas associated with this "software craftsmanship" movement seem beautiful, even noble.  It basically challenges some assumptions about the making of software, namely that it is strictly a kind of methodical and predictable process.  It makes a case that software engineering is as much a craft as it is a science or engineering discipline.  I like these ideas, I think.  One thing I'm not sure about is some of the ways that they phrase them.
From the "Manifesto for Software Craftsmanship" (http://manifesto.softwarecraftsmanship.org/):

"Not only working software, but also well-crafted software"

It's kind of unclear what this means.  I think it's supposed to mean all the things we as software people like in code design, such as reusability, readability, and robustness.  But putting it this way, in my opinion, is too vague.  It leaves it open to a lot of interpretation, and might be called "soft" or "washy" by outsiders.

"Not only customer collaborations, but also productive partnerships"

I don't really get this one either.  Isn't a 'customer collaboration' a kind of productive partnership?  Do all transactions in the software world have to be in the form of some kind of partnership?  I don't see anything particularly wrong with contracted work with a company that doesn't care about your company.  This statement in the manifesto seems to suggest every company you make software for should have a personal interest in your company.  If so, is that reasonable or even desirable?

I do agree with this movement that the coding skills of the developers themselves are important, but I don't agree that they're the most important.  To claim that's the most important part of a process as complex as software engineering is to close your eyes to so much.  The best coders the world over could be led into nowhere by clueless project managers or a marketing team not bringing in paying customers.  To claim that the quality of produced code is the most important aspect of a project is somehow noble, but appears misguided.  The quality of the code really makes little difference on what a system does; it makes a bigger difference on what the system can be made to do easily (i.e. modularity).