Real answer, taking all the above into account:
Regarding .svn directories: Subversion 1.7 was released a little over a year ago ( http://svn.haxx.se/dev/archive-2011-10/0152.shtml ) and the working copies no longer contain .svn directories in every folder. They contain a single .svn directory in the root, along with fairly substantial performance improvements. Today, SVN is up to version 1.7.7. You should upgrade your svn client to eliminate this as any sort of problem.
That answers the Original Question, because WP deleting the directories and re-creating them is no longer really an issue. It won’t mess up a Working Copy made by Subversion 1.7 or above. However, it doesn’t answer the larger question of repository management with regards to production deployment and dev/testing environments.
Basically, how you manage your production machines is up to you. If you actually have a real “production” environment, then you should use a permissions scheme and/or plugins to disable the ability of users to upgrade the system directly. Users can’t change production. That’s sort of the point of calling it “production”. Changes in such a case would be made by devs and rolled through testing and/or QA systems first. If you have such an environment and really need that sort of level of control, then disabling the upgrader entirely would be the preferred way to go.
Heck, I use just that sort of environment myself, although I control dev, testing, and production all the way through. The whole site is in an SVN repo. Some of it indeed uses externals (I use WP trunk, a few plugins I use as trunk versions), some of it doesn’t and is local to the repo. For me, deploying changes to production means doing an svn up on those boxes, basically. Changes can’t be made directly on those boxes filesystems.
On the other hand, some sites I run just straight up live, with regular backups. If my personal site is wonky for a bit, then it doesn’t really affect me any. I use the WP updater on those just fine. Now, I don’t run those sites in a repo, I just have regular backups of the whole thing. In point of fact, I use VaultPress on my personal sites, but any method of backup is a good idea. This is a different type of management, one where I don’t need a dev/testing environment.
WordPress works fine with any sort of system you wish to create around it, but that system is external to WordPress, and how you manage it is a question of not of WP but of how you want to manage it, really.