OK to modify HKLM\Software\Policies and HKCU\SOFTWARE\Policies on a domain?

Your understanding is correct.

When your company gets to the size that you need to bring in a dedicated Windows sysadmin they're going to be unhappy that you did this.

I can't imagine that your logic is so complex that it couldn't be solved by the built-in functionality in Group Policy. Security Group filtering, WMI filtering (which is performance-expensive but flexible), and Item-Level Targeting in Group Policy Preferences all bring a large amount of flexibility to the table. Sticking with stock operating system functionality means that you can get support from Microsoft and qualified third-parties, too. Tell us more about your logic needs, if you are so-inclined.

From a functionality perspective, you're throwing away a lot. The first few items that c ome to mind include background refresh, site awareness, SYSVOL redundancy, and stock OS management, logging, and reporting tools. I'm sure there are lot more that I'm not thinking of.

From a maintainability perspective: When you roll your own thing and it breaks you get to keep both pieces. When you leave the company you leave them "high and dry" with what may seem, to you, like something simple and self-documenting but, to the next person, will present some degree of learning curve (especially if your logic is so complex).

To speak to your comment re: version control - I'd argue that you can "version and diff" Group Policy Object settings fairly easily using the Powershell cmdlet Get-GPOReport, which can output an XML file containing the GPO settings.