Flexbox has been on our radar for a while as the eventual answer to "why is centering a div still hard," so we tried it on an internal tools page rather than client work, specifically so a bug or a rendering inconsistency wouldn't become a client-facing problem while we're still learning the syntax's rough edges.
Once you get past the older syntax variations still floating around in different browser versions, laying out a navigation bar with flex became noticeably less fiddly than the float and clearfix approach we've used for years. Centering an item vertically within its container, historically requiring a small pile of hacks depending on exactly what needed centering, became a couple of straightforward properties instead.
Why we're not shipping it yet
But support is inconsistent enough across the browsers our clients' visitors actually use that we're not ready to ship it on anything client-facing yet. The specification itself has also gone through revisions recently enough that some of what we're reading in older tutorials doesn't match the syntax that newer browser versions actually implement, which makes it hard to trust that code written against today's spec will still be correct advice by the time it would actually need to work reliably in production.
What we're doing with it in the meantime
We're keeping our internal tools page as a living experiment, rebuilding pieces of it in flexbox as we get more comfortable with the syntax, deliberately in a low-stakes environment where a rendering quirk costs us a few minutes of confusion rather than a client noticing something looks broken. Filed under: promising, keep watching, not yet ready for anything a client is paying for. We expect to revisit this again before too long, once browser support has settled further and the specification itself feels less like a moving target.
A concrete test case: the pricing comparison table
The specific thing that pushed us to actually try flexbox was a three-column pricing comparison table for the internal tools page, three boxes that needed to stay the same height regardless of how much copy went in each one, something that's genuinely annoying to fake reliably with floats without resorting to a background-image trick or JavaScript that measures and sets heights on load. display: flex on the container and align-items: stretch on the children solved it in about four lines of CSS, no JavaScript, no background-image hack, and no fixed height guessed at and then broken the next time someone edited the copy. Watching a problem we'd solved badly for years disappear that easily is exactly why we're paying attention to this rather than dismissing it as just another CSS fad.
We also tried nesting flex containers, a flex row of cards where each card was itself a flex column with a header, body, and footer, and ran into our first real gotcha: a flex item's default min-width isn't zero, which meant text inside a narrow column refused to wrap and just overflowed the card instead. Setting min-width: 0 explicitly on the child fixed it, but only after a confused twenty minutes assuming we'd made some other mistake, since nothing in the tutorials we'd read mentioned this default at all.