[unknown]
What is said in the Video is very much correct, for most application developers it won't matter a lot
Except now you as an application developer have to make a choice to either support GNOME's way of doing things, their look, and their theming in order to make it look less foreign under GNOME or take advantage of the widgets only found in libadwaita that should have been GTK4 widgets from the start (or updates to existing widgets), or make it so your GTK4 application does not look foreign everywhere else, on every other desktop environment, and lose out on those widgets.
That. Does. Matter.
but I agree that a lot of themes are just recolors
Maybe you and I are looking at different themes, but a fair few themes are not just recolors. Yes, there are objectively similarities in variants based on some themes, however most of those aren't based on Adwaita and don't want to be from the start. For example, there are fundamental design changes between Material-design oriented themes such as Materia and Plata, more Arc inspired themes like Skeuos, macOS inspired themes, etc. whether that is margin / padding changes, window control redesigns, toggle button changes, etc. Those aren't just colors, so a recoloring API does not re-introduce those options, not to mention a recoloring API (which is a mix of application developers individually supporting recoloring, and some CSS variables) doesn't mean the theme developer is able to tailor the theme to the desktop environment.
but I don't think there are a lot of projects as Budgie which make that kind of use of Gnome Theming
The desktop environment isn't the thing that has to support it. Yes, desktop environments can make it easier by providing CSS classes for those theme developers, but there is no shortage of Cinnamon, MATE, Budgie, XFCE themes.
I think that's a risk Budgie did take basing upon Gnome
The GTK toolkit is a fundamental part of Budgie 10 and all releases before it. It is a fundamental part of Cinnamon, MATE, and XFCE. It wasn't a risk that just Budgie took. It is a risk literally every single GTK-based desktop environment took.
it was basically a use of Gnome which wasn't intended by the developers
Well then that's one of the big problems, isn't it? That literally nobody got the memo, none of the desktop environments written in GTK (excluding elementary which basically hold hands with GNOME and are a proponent of this sort of locking down of control), that we suddenly shouldn't be using GTK as a basis for our desktop environments.
The argument time and time again by these libadwaita developers is that this enables GTK4 to be more generic. Except nobody wanted that to begin with. They just didn't want GNOME ripping out the carpet from underneath folks. Now everybody has to either choose to use libadwaita (which then forces adwaita) or build out their own widget libraries, which further fractures the use of graphical applications across multiple desktop environments. You have to implement your own recoloring & theming APIs because one of the lead GTK developers opted to just close their patch rather than fight with designers from GNOME and elementary. His words, not mine. You have to implement your own support for various new freedesktop standards, rather than that being part of the toolkit. You have to implement your own widgets for basic functionality that should have been in GTK4 now, like "Avatar" image, Carousels (fancy GtkStacks), "Flaps", all the programmatic preference window bits, and more.
