If you must hack core, consider doing so in a way that makes it extensible for others.
Add an Action Hook
Nine times out of ten, you could do what it is you wanted if only there was an extra do_action call in a specific file. In that case, add the action, document it, and submit a patch via Trac. If there’s a good reason for your patch (i.e. you’re not the only one who would ever use it) then you can probably get it added to core.
Next, build a custom plug-in (you don’t have to release/distribute it!) that ties in to this new hook and performs whatever function you need it to do.
Refactor a core file
Other times, you might just need a piece of code to behave differently. Pass a variable by reference, for example, or return a value rather than echo it. Take some time to sit down and refactor the code so it does what you need it to do … then submit a patch via Trac so the rest of us can benefit from your work.
Do you see a theme developing here? Hacking core isn’t necessarily a no-no … just something most developers will highly discourage for new users or novice programmers (if you’re asking us how to do something, we’ll suggest a plug-in every time before even considering to suggest you hack core).
Hacking core is the way WordPress develops and evolves, but it’s dangerous for someone just learning PHP or with no experience working with WP files. Please start with a plug-in before touching core – if you break a plug-in you can uninstall it quickly (removing via FTP if necessary) … but if you break core, bad things can happen to your site and potentially to your database as well.
But if you are in a situation where a core hack is unavoidable, then make the change. Also, publish your change in a prominent location (if your blog is highly visible, that might be sufficient … but I suggest Trac because that’s how community changes get pulled into the next release). Your change might be the magic bullet that could fix problems in a hundred different sites … so contribute back to the community that helped you build your site.
If the change gets committed, then your hack becomes part of core and you won’t need to worry about it in the future. If it doesn’t, at least you have detailed documentation on how to re-implement the hack after you upgrade WP in 3 months.