> I can't comment on the current state of MacOS since the time I've spent actually using a Mac during the last 8 years or so probably totals to a few hours. Apple used to be good at this, and I hear they still do a decent job at keeping things sane, even post-Jobs.
The macOS menu bar is still compulsory. First party apps generally still fill it out properly with commands for everything a user can do and put the common ones in their usual places. For third party apps it depends on whether the developer put time into platform norms. Many Electron apps don't: Slack makes many commands available only through UI popup menus; VS Code puts them in the command palette so you can only find them by search. Of course these apps have key shortcuts but you can't learn them from a menu bar item that doesn't exist.
The focused window gets a heavy shadow. I think that's also compulsory.
But first party apps and recently the system frameworks are guilty of cramming toolbars into title bars and leaving a drag area that doesn't span the width of the window. That's permanent. At least the window title is still written and you know you can drag that. A window's file proxy icon is often missing until you hover on the title. The bar at the top of the window may or may not be visually divided from the content area.
First party apps also remove color and/or silhouette distinctiveness from those toolbars' buttons. App icon silhouettes are also gone.
Scroll bars are of course hidden by default but can be always shown.
The result is probably more usable than what's described in this article on other platforms, but off peak for macOS.
Aside: iOS started the hidden-unless-scrolling scroll indicators trend, I think. Platform guidance was that you're supposed to flash them on first appearance of any scroll view whose content doesn't all fit. (To try it out, go to the Home Screen and then back to Safari.) This is the signal to the user that there is more to see. Users don't consciously think about it but they pick up the right expectation. You just call a method[1] after the view transition animation finishes. This has become arcane knowledge in the iOS field: No one remembers this is important to do in the absence of persistent scroll bars, and where it's not automatic due to using system frameworks in a high level way, many apps just don't get this right.
[1]: https://developer.apple.com/documentation/uikit/uiscrollview...