Nowadays on macOS, with the availability of the CLI, Apple engineers have decided to expose those same effects through CLI utilities that call directly into private system APIs (which are themselves usually client libraries for private Mach client-server ABIs.) If there's a switch exposed in the GUI but not the CLI, it's unlikely there's an event to reach it any more.
(Though, in macOS or Windows or Linux, it's always a possibility to write a script that has GUI effects directly in terms of "click the first button on the right"-style accessibility directions. But that's extremely brittle to system version updates, and precisely the thing that exposing an automation API is meant to avoid.)
You're right that a lot of GUIs aren't designed for automation, but CLIs aren't the only answer. Classic MacOS had a powerful scripting architecture. (It still exists, but it's been neglected.)
I think the issue is not so much "command line hides power and treats GUI like a second-class citizen", though that is true, but rather that preferring one over the other creates problems.
This issue is again rearing its head in website design - many "web applications" have states that are not reachable via linking.