@djay... yes it is a ruleset to shield "casual" designers from Diazo.
Firstly some context:
The overarching philosophy of Gloss is to keep designers happy and save developers from reimplementing the designer's work, Diazo provides the toolkit to do this, Gloss is an opinionated implementation.
I tend to make a distinction between a Gloss themer (Basic theming with CSS gl- classes for content assignment) and a Diazo themer (Advanced theming with Diazo directives and XSLT). More complex stuff generally aligns with what I classify as 'Advanced theming'. My current solution for Basic themers is gl- classes via Gloss, and for advanced themers, we provide a cheat sheet of common Diazo recipes. BTW there is only a small overlap between those who are fluent with Diazo and those who are empathetic designers.
To answer your questions....
Is it easy for the themer to know when this approach won't work? ie how to determine a theme is too complex.
The documentation is the trick here, it provides a list of gl- classes and what they do. You know you need to go further if none of the gl- classes do what you want. In the case of compelling new scenarios that are not supported, Gloss users would be encouraged to file a ticket for an enhancement and then, if it is practical, it would be added to Gloss. see: http://the-gloss-project.readthedocs.org/en/master/reference.html
If a design is too complex, is it then easy to copy the diazo rules (or include them) and add more rules to do just that extra part? e.g. like some tricky navigation or something?
Gloss rules can be easily added to other themes and, because they are fully compatible with Diazo they can be extended with "traditional" Diazo theming approaches, we do this in our projects now.
Is is possible to base rebuild barceloneta like this?
If you mean add Gloss like rules to the barceloneta base theme so that it supports gl- content assignment classes, yes and it should not affect the existing barceloneta theme since all Gloss related rules are filtered on the gl- "namespace".
is there any reason not include this approach in the core if its a smooth learning curve to using diazo for more complex stuff?
I don't know, I think the learning curve is pretty smooth.
The big threat is it becoming unwieldily, for example I've started to add support for what I call 'components', e.g. drop down menus and sliders (see: http://the-gloss-project.readthedocs.org/en/master/components.html). These are early days for components, but imagine being able to 'decorate' a slider in your theme with a with a few extra gl- classes and magically it would dynamically pull in images from a Plone Carousel. Unfortunately at the moment this has to depend on third-party packages like webcouturier.dropdownmenu and the carousel add-ons. When Plone moved to Plone 5 and webcouturier.dropdownmenu did not it broke gl- support for dropdown menus. As long as we are aware of this we can navigate carefully but it is an important consideration if you're thinking of adding it to the core.
"/me thinks he should do a presentation on Gloss at the next Plone conference"