The vast majority of my library is video. My fear is taking some innocuous action in MC (audio analysis of video files, hand tagging, etc.) triggering a multi-TB incremental backup. It seems better to keep tags adjacent to large files instead of inside them.
For almost every kind of video file I've encountered MC already uses sidecars instead of writing to the file. Certainly true for .mkv, .ts, .avi files etc. So what you're asking for is kind of already the situation for most video files (IME anyway).
I don't have any .wmv files, but I would expect any issue you're experiencing would be limited to files that can store tags inside them (which is pretty atypical for video files). Audio is different, as most formats support embedded tagging.
You can control whether files get tags written to them as Arindelle mentioned if this is a dealbreaker for you, but be sure to backup your library regularly.
I guess I'm asking if I am violating some kind of 'best practices' with MC? Or, is it normal for a small tag adjustment to cause a n-GB file to change?
Any change in tags that gets written to a file will obviously change the date stamp. Whether that triggers a backup of the entire file or just the changed section really depends on your backup solution, not on MC.
For example, I use an rsync-based backup solution,* and if I edit embedded tags rsync just sends the changed parts of the file, not the whole file. Modern de-duplicating backup systems send even less information than rsync. However, some backup systems send the whole file everytime, which is obviously suboptimal (but it sounds like that's what your solution is doing).
So you're not violating MC best practices, but you might want to look into a more granular backup solution if your solution sends the whole file anytime something changes (which is kind of surprising behavior with modern backup software TBH given that rsync is FOSS and solved this problem 20 years ago).
*NB: On the off chance you're already using an rsync-based solution, it may be defaulting to whole file transmission if both locations are perceived as "local," in which case you need to make sure to pass the --no-whole-file flag to force it to only do a delta backup (this will mostly help speed things up if bandwidth is your bottleneck, rather than disk i/o, but will transmit less data for sure).
Are most peoples' tags effectively invariant?
After initial setup and analysis, my tags rarely change, but when there are significant tag changes to files with embedded tags (i.e. mostly audio files), I expect to see a somewhat larger backup load. Again, the load will depend on your backup solution, my load increases based on the number of files changed, but definitely does not require re-transmitting the full files (or anything close to it).
ps. For the 'wmv' files that got caught up in the backup, it appears MC set a field called 'beats-per-minute' into the wmv itself.
That's an audio analysis field, and shouldn't ever be "reset" once it's set, so I wouldn't expect this specific issue to recur.