I am a WordPress hobbyist in the true sense of the word. I have released one theme into the .org repository (I stopped work on it after it was removed from the directory in mid-2016 for not using the Customizer) and a handful of plugins (of which I have been actively maintain one since 2011). All my projects are and have been 100% free, both in terms of code and cost; I have a "coffee" button tucked away but that is only for people who insist on paying for my code.

I use the term "hobbyist" because WP has nothing to do with my day job and I code with it purely to stay abreast of web technologies and terminology. When it comes to putting food on the table, WordPress is akin to a rounding error in my case. My guess is that there are a few others like me, though I doubt that the number of such people would go beyond double-digits.

As a hobbyist, in the past I found the theme directory guidelines getting exceedingly draconian with every passing month. To me, the crux of the problem lay in WP itself not building things into the core for a long time and preferring the mantra, "There is a plugin for that".

As an example, Menus were introduced in WP 3.0 in June 2010 (adapted from Woo's offering), but for a long time there was no way to automatically add pages or categories to it. In the meanwhile, since menus are considered design elements, most themes had to come up with ways to manage menus. As a net result, when the native menu system finally matured a few years later, theme developers were asked to remove their own implementations in favour of the native. The native feature was a welcome one, but it would have been so much better if the initial release in 3.0 was more full-featured.

Similarly, the customizer was introduced 2 years later in June 2012, by which time pretty much every theme had its own options panel. Some options panels were so comprehensive that moving to the customizer felt like a massive regression as far as the interface was concerned, never mind the talk about live updates being visible. A paraphrased conversation between the developer and the review team typically went this way:

Dev: My theme's options panel is very complex. Recoding it to fit into the customizer will take a lot of effort.
WPTRT: It can be done. You have to do it.
Dev: What takes 2 clicks to reach now will take 6 clicks in the customizer. Going from one option in one panel to another option in a different panel requires a user to navigate all the way back to the top, then navigate down to the other option.
WPTRT: Think of a user coming from a different theme - they will be used to the customizer.
Dev: The live update feature will take a long time to code for the number of options that I have.
WPTRT: You don't have to code for live updates.
Dev: Then what is the use of ripping apart my whole framework?
WPTRT: Again, think of a user coming from a different theme - they will be used to the customizer.

The desire to use the customizer might have been a noble one, but ramming it down the theme developers' throats when it would cause development and usability issues without gain was not particularly smart. I am pretty sure I have seen posts on this forum that have admitted that, in hindsight, the customizer wasn't good. I would contend that an options panel built using the Settings API should have been allowed to coexist with the customizer. If necessary, more stringent guidelines could be laid out for the Settings API to drive standardization. I am pretty sure that several "marketplace" themes largely steered clear of the customizer, hence retained the perception of being more user-friendly and innovative.

The common refrain had always been, "Themes should not implement plugin territory features". But menus, options panels, widgets / widget areas, layouts etc. were never really plugin territory features - it is just that for a variety of reasons theme authors had to build in implementations to overcome WP's native shortcomings. As things got added to the core, instead of alternative (and innovative) implementations being allowed to coexist, theme developers were arm-twisted to overhaul their code (or have their themes culled from the repo for not complying).

The changes outlined in this post are welcome for sure, but I will not be holding my breath to see if they drive any meaningful change. I have been down this road quite a few times, and I am sure that the rules will soon change and degenerate into something that will become unsustainable for a whole new army of developers.