"Aren't there problems that can only be solved by hacking core? What
To answer this question, yes, there are sometimes problems you have to overcome that mean you have to hack core (or a contrib module).
In this case I believe it is ok to hack as long as you put lots of comments in your hacked code and document everything you change.
For example, for any core or contrib change I make I create a patch. If it is generic and useful to other people I submit it to drupal.org in an issue, otherwise it is for my own use.
I then commit the patch file to my version control along with the code change.
This means that I can see by looking for patch files if something has been hacked.
In addition to that, I also add a list of hacks to the developer documentation for the site (you really should have developer documentation for the sake of others that might work on the site and for yourself when you inevitibly forget things).
In this hacks documentation I list each hack with what the hack does and why, modules/files affected, the name of the patch file that contains the hack code, and a link to a related drupal.org issue if there is one (almost always in my case there is).
Then you and whoever else works on the site in future has a full list of hacks and doesn't have to worry about accidentally breaking something with an update.
Then for the update process I check my list of hacks and have a quick look for patch files in all the modules I am updating.
If there is a hack and it has a drupal.org issue, I check the issue to see if the latest version has the patch included, in which case I blow away the hack with the update and remove it from my list of hacks (make sure by looking at the drupal.org commit messages that what was committed was the same as the version of the patch you are using, or at least in functionally the same).
If the patch was not committed, all I have to do it update the modules and reapply the patches. In a lot of cases the patches will still apply cleanly and the process is easy, but sometimes you have to reroll the patches for the new version and then commit the new version of the patch to your local repository (along with posting it to the relevant drupal.org issue where applicable).
Another thing I like to do if I have more substantial patches or patches that interact with core fucntionality of a module (or just custom modules that extend on top of a drupal.org module), is to check the release notes of the updated module (that means all version in between your current version and the version you are updating to) and make sure there is nothing in there that is likely to break your code.
Note: A lot of module maintainers are good these days with giving complete release notes but there are still a lot that do rubbish release notes. In this case in some cases I go through all the commit messages since my current version (this is usually only in cases where I have complex code that interacts deeply with another module).
Note: In this case it might be easier to do a diff between the version you have and the new version to see what has changed.
Then, after updating (on a development copy of the site), test thoroughly.
You will eventually learn what thoroughly means after a few bugs slip through.
Then when it has been tested sufficiently, upgrade the live site or push your local updates up or whatever your deployment process might be.
The reason why everyone says don't do it, even if it is easier:
Because most people don't have a system like I have outlined, so when it comes time to do updates, or the site is handed to someone else to work on, it becomes a nightmare and a lot of time (sometimes an enormous amount of time) has to be spent solving bugs and tracking down hacks and working out why they are there, etc.
If you ever inherit a site like that you will fully understand :)