Generally speaking, there are three reasons for not altering the Drupal core code:

• Your changes would be lost each time you update Drupal, if you don't take any necessary steps. Even in the case you create a patch for the current Drupal version you are using, the patch could not apply to the newer version, and you would need to create a patch for the new version too.

• Security fixes apply to the Drupal core as maintained on Drupal.org, but could not apply to your hacked version. That means you should check your version is not affected by the security issue raised against Drupal core.
  In the case your hacked version introduces a different security issue, you are the only person you can find it, as you don't have the support of the security team that investigate on security flaws present in Drupal core code, and in third-party modules hosted on Drupal.org.

• The changes you introduce could be incompatible with Drupal itself, but also with third-party modules, which are required to work with Drupal core, not with any hacked version one can create.
  Every time Drupal introduces a new feature (which still happens in Drupal 7, and in Drupal 6, although with less frequency), or a new API change, there is the chance the hacked version is incompatible with the recent changes.

That said, it is possible to create an hacked version, but that is not the task a single developer can carry, in the same way Drupal is not maintained by a single person. In fact, Pressflow is an hacked version of Drupal that has been created with performance in mind, and to resolve some performance issues a Drupal site could have.

Aren't there problems that can only be solved by hacking core? What then?

Most of the times, it is possible to alter the features/behavior without editing Drupal core code. There is always a hook that allow to change the features/behaviors Drupal has, and that is the preferred method.

Generally speaking, there are three reasons for not altering the Drupal core code:

• Your changes would be lost each time you update Drupal, if you don't take any necessary steps. Even in the case you create a patch for the current Drupal version you are using, the patch could not apply to the newer version, and you would need to create a patch for the new version too.

• Security fixes apply to the Drupal core as maintained on Drupal.org, but could not apply to your hacked version. That means you should check your version is not affected by the security issue raised against Drupal core.
  In the case your hacked version introduces a different security issue, you are the only person you can find it, as you don't have the support of the security team that investigate on security flaws present in Drupal core code, and in third-party modules hosted on Drupal.org.

• The changes you introduce could be incompatible with Drupal itself, but also with third-party modules, which are required to work with Drupal core, not with any hacked version one can create.
  Every time Drupal introduces a new feature (which still happens in Drupal 7, and in Drupal 6, although with less frequency), or a new API change, there is the chance the hacked version is incompatible with the recent changes.

That said, it is possible to create an hacked version, but that is not the task a single developer can carry, in the same way Drupal is not maintained by a single person. In fact, Pressflow is an hacked version of Drupal that has been created with performance in mind, and to resolve some performance issues a Drupal site could have.

Aren't there problems that can only be solved by hacking core? What then?

Most of the times, it is possible to alter the features/behavior without editing Drupal core code. There is always a hook that allows to change the features/behaviors Drupal has, and that is the preferred method.