They justify the rejection of SSD because it isn’t part of the core Wayland protocol and at the same time push client apps for the “minimize” and “maximize” buttons (along with respecting some settings) despite it also not being part of the core protocol and it being only possible through extensions. There’s a ton of tiling compositors that don’t even have any concept of minimize/maximize, so why should this be required of every client app?
It feels backwards to ask the app developers to be the ones adding the UI for whatever features the window compositor might decide to have. They might as well be asking all app developers to add a “fullscreen” button to the decoration, or a “sticky” button, or a “roll up”/“shade” button like many old school X11 WM used to have. This would lead to apps lagging behind in terms of what they have implemented support for and resulting in inconsistent UX, and at the same time limiting the flexibility and user customization of the decorations, not just in terms of visuals but also function and behavior.
Even in this case I’d argue that on small screens most apps simply have no real decorations (not even client-side)… there’s typically not even a close button. Hamburger buttons are menus, which isn’t what’s typically considered “decoration”. One could argue that the bar at the bottom in Android with home/back/etc controls is effectively a form of SSD. Android offers system UI or gestures to send the app to the background (ie. minimize) or closing it, it does not require Apps to render their own, which is effectively what Gnome is asking with CSD.