The disconnect between these two has been highlighted by recent events.
The end requirement was clear. A couple of changes that the business wanted, prioritized and re-prioritized to a certain list. A couple of changes that could be completed in a few days and fit into the long list of various requirements that the business wants, a business that has very little resources available for testing.
The developer in question though sees the ugliness in the entire codebase, it makes him uncomfortable. He sees all of the places where it goes against what a software craftsman believes in. He's a talented developer, dedicated to his craft. So, he spends a couple of weeks to rewrite the application in fundamental ways that completely changes how most of the application works.
Let us posit without question (though there are always questions here) that the developer is a good developer and that the changes he made are good changes (in the particular case, this isn't true, but let's put that aside), that the developer did what he thought was the right thing to do, from a codebase perspective.
What the developer did that was wrong was to confuse his own desires from what was needed by the business. Even given what was posited, he extended timelines and made changes not requested by the consumers of the application that he was working on, changes that required extensive re-testing of the application in ways unexpected and unwanted.
This is the true danger of software craftsmanship, developers who care more about their own idealized thoughts as to how software should be written than the software that is actually wanted.