Clients seem to come in sets. A couple months back, I had several clients who had hired cheap off-shore companies 12 time zones away whose developers were curiously unavailable by phone, email or carrier pigeon. You probably already know the rest of the story: client needed to spend more money to have someone else go in and try to make it all work. (BTW, always use the term "refactored" rather than "threw out" when referring to the busted up stuff the client paid for).
Lately the theme has been clients who hired a 'Drupal developer' to do custom development and ended up with hacked up Drupal core, semi-working custom functionality and lots of odd behavior in different parts of the system. As an intelligent, hip, effective web entrepreneur, you should not strive for this.
Gumby -vs- Pet Rock
The typical LAMP application is made up of a tightly coupled set of code that all works in unison. While you may be able to configure this type of application, you cannot easily create or remove core functionality yourself. There is absolutely nothing wrong with this approach if you're developing a closed system designed to be maintained by a relatively small group of developers and whose feature set is pretty easy to anticipate and can be built in from the ground up. But this approach is not a good one for something like a CMS.
Why, you ask? Well, this is quite a coincidence as I was just preparing to answer that very question. Unlike more specialized applications (think phpbb, phpmyadmin, photo galleries, etc...), a good CMS is something that you should be able to extend, possibly in ways never imagined by the authors of the software. This type of extensibility separates applications like Google Maps from MapQuest. Like Gumby, Google Maps can be made to do any number of things never thought of by Google (from a developers perspective). And like a pet rock (did I just give away my age?), MapQuest pretty much does what it does, and if you want it to make it do something else, that's too bad, you should be using Google Maps, fool!
The number one quality that separates Drupal from other popular CMS is its API (most often referred to as "the Drupal API). Drupal is designed explicitly to allow for adding, altering or removing core functionality. Thanks to this API, there are hundreds of third party modules available for Drupal. Some of these modules provide very specialized features. Others provide integration with the most popular services on the web (including Google Maps, Flickr, del.icio.us, Digg and more). All take advantage of the Drupal API and none include modification of core (again, the basic code base required to run Drupal).
Enhancing software that doesn't provide an API usually involves modifying its core code directly. If software doesn't open up its functionality to developers, then developers are left to go in and manipulate the original source code to achieve their goals. In many cases, this is just how you have to do things. Drupal is not one of those cases.
To be clear, when I refer to 'hacked Drupal core', I'm referring specifically to modifications of the files that come with the standard distribution of Drupal, most importantly, the files that are in the /includes/ and /modules/ directories. All of the same concepts apply as well to third party modules, but that's not what I'll be focusing on here.
Does it really make a difference whether you do things correctly as long as they work? Absolutely. While it may seem much more effective at first to edit Drupal core to add the features you want, this is a big mistake. Let's talk about some of the problems you will run into.
The first problem you'll likely run into is applying Drupal updates. The Drupal team is excellent about patching security vulnerabilities. This means that if you are steadfast in keeping your Drupal instance updated, your chances of getting 'hacked' are greatly reduced. However, if your team has modified Drupal core, applying updates becomes a painful process requiring careful scrutiny of each update and possibly an even more painful merge of those changes with your hacked core files. In my experience, rather than go through this unpleasant process, owners of sites with a hacked core tend to postpone applying patches and updates. The more the owner procrastinates, the more likely his site is to suffer an attack using a known exploit. Once your site has been exploited, there's no telling how long your site may be down or how long it will take you to recover.
The next problem you may run into is broken functionality. By altering Drupal core files, you may be inadvertently modifying functionality depended upon by other parts of the system. You are messing around inside the "black box" that Drupal as a whole depends on. While you may think it's clever to go in and modify the phptemplate engine directly, what you could be very well doing is creating bugs somewhere else in your site. By the time you come across the problem, it is unlikely that you'll immediately realize that it is caused by the changes you made to phptemplate. And, friend, you are now in for a lot of hurt as you rip apart code trying to fix it.
Maintainability and Longevity
Drupal's API is known by hundreds of developers all around the globe. The hacks introduced by your $20/hr programmer found on craigslist are known only to one developer. Should you ever need to update or extend your site, you better have that $25/hr developer on staff or you better be using the Drupal API. If you play by the rules, you can hire any experienced Drupal developer.
There are legitimate reasons to modify Drupal core. If you've found an actual bug in Drupal, the best thing you can do as a developer is to fix it and submit a patch. Likewise, if you've come up with an enhancement that you feel should live in core, submit it. Aside from these two reasons, neither you nor anyone in your employ should be touching anything in that drupal .tgz file.
If you want to develop extended functionality for Drupal, use the API. If you're hiring a Drupal consultant, find one who is familiar with the Drupal API. Find a developer who's active in the Drupal community. Hiring a knowledge Drupal developer may cost more initially, but if you plan on maintaining your site for any length of time, this investment is sure to pay off down the road.