You can reproduce a fair bit of Grid using just Flexbox (and we did that for quite a while before Grid came along)—but it's going to be far more verbose, both your HTML and CSS, and probably more brittle and complicated to change.
If you're setting precise sizes in flexbox, or very specific flex values, you're probably in Grid territory. Ideally, flexbox is best when you want things to stretch/shrink to fit and you want the items to determine their own sizes. Grid is best when you have a specific layout/sizes in mind, and you want to impose that layout onto the items.
Apart from the semantic issues that result when littering your HTML with <table> tags that inaccurately represent the content they contain, Grid also provides features that tables cannot do:
* overlapping cells (http://gridbyexample.com/examples/example15/)
* empty cells, without a bunch of empty <td> tags (http://gridbyexample.com/examples/example12/)
* size columns (or rows!) in proportion to one another
* complex alignment of contents within a cell (http://gridbyexample.com/examples/example24/ and http://gridbyexample.com/examples/example25/)
* specify exact min and max sizes for columns & rows
* provide a full definition of responsive behavior, often without any media queries
It also provides everything a table does with far less code and easier to read markup.
HTML is not just about putting text on a screen. It is markup; the tags and attributes imply meaning about the contents they contain.
This makes it not only usable by a web browser, but parsable by software. That includes, but is certainly not limited to, screen readers, assistive technologies, and search engines.
Consider an example where I use JavaScript to make <i> tags behave like links. I can make it “work”, but by doing so, I am disregarding—and breaking—a primary function of the language.
It's perhaps not as custom as I made it sound. The code we have is a wrapper around the [virtual-dom](https://github.com/Matt-Esch/virtual-dom) library which does most of the low level work.
The "widget" framework is a series of simple ES6 classes that allow us to keep state around and delegate events as actions up to Ember controllers. We had a lot of pre-existing, battle tested code that was written using Ember idioms and was not a performance problem, so we kept that around and used the virtual dom stuff just for rendering HTML as fast as possible.
Why not React? Our main pain point was rendering, and we didn't need all the extra stuff React provided as those bases were already covered by Ember. Why include 26k min+gzip when we would only use a small part of it that was already provided by another excellent virtual-dom library?
If you're setting precise sizes in flexbox, or very specific flex values, you're probably in Grid territory. Ideally, flexbox is best when you want things to stretch/shrink to fit and you want the items to determine their own sizes. Grid is best when you have a specific layout/sizes in mind, and you want to impose that layout onto the items.