I've got a bit of a story for this:
I'm currently designing an app which uses wxWidgets. wx was conceived in the 90s, and operates on the assumption that all controls should be system-native, and that apps should be similar to each other on an OS to avoid having to re-learn patterns all the time.
Today, this is our greatest pain-point, both in development and user perception. It's not necessarily evident in menus, but take this slider for example:
The screenshot examples here are a bit outdated - the Windows appearance of this slider now has a blue thumbtack in the middle, rather than a green/white one - but the problem is evident: A slider on Windows and Mac means "middle", the very same thing on Linux means "half full". This is a meaningful difference; if the slider goes from 0 to 100, the wxGTK appearance makes a ton of sense, if the slider goes from -50 to +50, it doesn't - why would 0 have any tail at all?
If I want to use one or the other version, it's unlikely for the OS to come along and provide me with the option, so the only solution is for us to build our own slider. And if a click into the slider means "move 10% in the click direction" on one OS but "move exactly to where the user clicked" on another, I could make the design specify different behaviors on different OSes, or I could prioritize consistency within my app no matter what OS the user is on.
The same applies to many other standard components - using the standard components is okay, until a component gets in my way. Incidentally, in my area this comes up constantly as making an audio editor in 2023 has very different component requirements than office apps had in 1992. We'll be switching to QML instead and have ~everything custom in the near-ish future.
In the case of the window title bar, it's an entire bar, often the width of your screen, which contains 3 buttons in one corner, a grabbable area, and then a menu which just repeats these options again. Any app running into space constraints and any app designer looking at the 5 stacked toolbars in their app is therefore looking at the titlebar and thinking "what if".
In the case of recent versions of Gnome/Adwaita, all major browsers and even Windows' default apps (eg Windows 11's Explorer and Settings apps), they've all come to the conclusion that the concept of a titlebar is taking up too much space, and that it's better filled with tabs, menus and other stuff. Removing the window menu in the process is messing with your "deeply-ingrained user expectations", but the overwhelming majority probably has never used this menu, or the "double click to close". Why would they, if the big red X is right there?
With all that said:
- Is it a good idea to disobey system standards? Yes, if you have a good reason for it. In the case of ellipses (eg "Print..." vs "Print"), I'd even go as far as saying that the standards are outdated and disobeying them should be the default.
- NB: Disobeying them just to be different typically isn't a good reason.
- Is it a good idea to remove the window menu? Yes-ish. All of its functions are available via other means to abled users. To disabled users, keeping Alt+Space available might be useful, but if that's not possible, limited resizing and moving is available via Windows key+Arrows. Having a full replacement would be ideal (Gnome uses Alt+F7/F8).