I’ve done a good amount of GUI and non-GUI programming in C# and F#, in work and play, heavy programmatic and static… and I believe your stated impression is accurate and practical. (note that I am more familiar with WinForms than with WPF, but I don’t think the differences matter here).
My impression is that C#+XAML let you build static GUIs (a few
sliders, a few text boxes etc.) easily but I cannot see how the GUI
designer would help with programmatic GUIs like a business rules
engine.
This is absolutely my experience. For mostly static GUIs, I prefer using the WinForms designer with C#. The tooling combo is great for these scenarios and is more productive than hand-coding the GUI with F# and no designer (now, if there were F# support with the designer, I would have no hesitation preferring that). I’m Only Resting is an example where I have preferred C# with the WinForms designer over pure F#.
And for heavy programmatic GUIs, I believe it is best to avoid the designer altogether, rather than to attempt to go half designer half programmatic (it gets real messy, real quick). So in these cases I definitely prefer hand-coding the GUIs in F#, since everyone knows F# is the more expressive language 😉 FsEye is an example where I have preferred pure F# over C# with the WinForms designer.
Am I right in thinking that maintaining a battery of mostly-static
GUIs (e.g. adding a new field to 100 separate GUIs) will require
manual labor?
Probably. I don’t believe there is really any ready solution for this problem since it is really quite a large one. But there might be some best practices out there for building a custom solution right for your suite of software.
Also, am I right in thinking that the GUI designer is of little use in
the context of heavily programmatic GUIs so something like a business
rules engine would be written primarily in C#+XAML with little use of
the GUI designer?
Yes, like I said early, it is my belief that you ought not try to mix the GUI designer with heavy programmatic GUI programming.