Yep, I also find people don't notice the changes usually go both ways as well, where it's common that some requirements change a little or get dropped in a way that makes your life easier. It's great when both sides can be reasonable and non-adversarial about it all. A deadline with a well-defined goal helps a lot too, over a rigid list of requirements.
> To hedge against this, I tend to include a bucket of hours for arbitrary changes.
Can you explain this part more? How do you explain what gets charged against the bucket of hours and how many hours for each change? At what stage do you issue change orders?
Small thing I don't hear people mention but with the SOW I always add a list of "not in scope" items too (e.g. "web app works in latest version of Chrome only" + "Internet Explorer and mobile support is out of scope"). I find this help uncover ambiguities like the client saying later "I assumed it would have worked on mobile Chrome and desktop Edge too", and makes it much easier to say "we agreed that's out of scope".