Is it good form to scrub development code from my source files during a pre-commit hook?
For example, I have code that is calling xdebug_break() and I want to remove the calls to that function from any files that have it before committing my code to the repository. I would rather not check for the function before calling it because I am the only one that wants that function call there.
The pre-commit hook should only be used for checking the commit, not for modifying it. So, you could use it to check if you have the undesired code in your commit, and abort the commit if you don't, but you should not use it to modify the commit in any way.
It would be possible to use a filter attribute to run a program to "clean" your sources before they are committed; but I would recommend against this. Removing lines of source code can change the behavior of your program. You should not commit any work that you have not tested in the form that it is being committed.
It's ok to have the precommit hook modify code before committing it. For example, a development team might use the precommit hook to automatically reformat any code that is committed to automatically enforce that team coding conventions.
Based on the comment, I'm changing my answer - the svn manual specifically recommends AGAINST changing the contents of a commit because it can screw up the client side caching. Git works differently since the repository is local, but I guess the principle is the same.
As for the specific use case that you mentioned; it does seem a a little unconventional to use the precommit hook for that. Typically, the precommit hook is used for more general purposes. That said, if you're the only developer, you're free to use it however you like. Just don't forget that it's there.