The only alteration I currently make to the raws is the one to be able to see and enable/disable all non-economic stone from the (z)Status->Stone screen, along with which ones are magma-safe.
I've often gone memory hacking, though, to tweak the coordinates of the hotkey viewports. I never liked how the viewport's center would be offset just a few tiles from what I wanted to be the center of the screen. So I'd go hunting through memory for the current values, adjust them to my desired position, and then resave the hotkeys.
I've taken this one step further, now. I realized that I use a 12-unit offset in nearly all of my designs. (11x11 rooms, which can be divided down into 4 5x5s, 9 3x3s, 16 2x2s, or even 36 1x1s.) But the normal viewport scroll is a 10-unit offset. I tried designing a fort using 9x9 rooms as the basis, and it was actually great in that the fortress now lined up with the scroll amount. But a 10-unit offset is so much harder to work with than a 12-unit offset, in terms of design.
The obvious solution? Change the scroll amount. So I brushed up on my assembly, dug into the executable file, used some debugging tools to locate the relevant code bits, and altered them (literally, I was almost always toggling single bits in an instruction). Now I have a 12-unit viewport scroll amount, but still have a 10-unit cursor scroll amount so that those 11x11 rooms are still super-easy to designate. It'll be a bit of a pain to do it for every release, but I might slowly develop a good system for making it quick, depending on how I see the code change over releases. At the very least, I kept good notes when doing it last night, so hopefully next time it'll be a matter of a search/replace in a hex editor. Unless the compiler arbitrarily decides to put the machine instructions in a slightly different order or use slightly different instructions for no particular reason. Then it's back to the debugger. It was a fun learning experience, but merely tedious now that I know what I'm doing.