This is horrible, IMHO. Flex containers will layout the flex items, which are by definition its direct descendants. If by some reason [1] you get an extra DOM element between the flex container and the item you intend to layout, then you're in for a rewrite of the CSS and maybe some extra classes.
Yes! Flex box has lots going for it, but it breaks a "feature" that many web developers and framework developers have relied on since the earliest days: it being mostly harmless add an extra layer of element at a whim anywhere. One could argue this is a lousy feature (and I would agree). But lots of developers and lots of frameworks do it.
Adding elements just because (and, above it all, just for styling purposes) is wrong, of course. But having - or forcing - a tight coupling between structure (DOM) and layout/styling (CSS) is also wrong. IMHO, standards should try to move in the direction of decoupling; they did the opposite with Flexbox.
Anyway, the most present case for me is really Angular, where DOM elements are usually added because they are needed (and actually beneficial, if you like a component-based architecture and DRYness). Angular 1.x deprecated the `replace` option for element directives a few months ago (i.e. your <my-directive> will be in the DOM). Also, AFAIK, it never supported the `replace` behaviour in components (which are always elements). This means that, currently, Angular and Flexbox don't play very well together...
This is horrible, IMHO. Flex containers will layout the flex items, which are by definition its direct descendants. If by some reason [1] you get an extra DOM element between the flex container and the item you intend to layout, then you're in for a rewrite of the CSS and maybe some extra classes.
Also, this bug in Webkit is rather inconvenient: https://github.com/philipwalton/flexbugs/issues/115
[1] For instance, if you create an Angular element directive.