React components that take configuration rather than allowing you to compose smaller components are generally a bad idea.
In my experience with React, this kind of approach produces much more readable and elegant code. And also less code. And as long as the configuration objects are simple and readable like these, the problems with it are not serious.
It's true though that when your needs get more specific and complex you will surely find you need something not included in the component's configuration options. In those cases some components will let you specify custom things, which may or may not be enough[1].
Then it's trivial to reuse that configuration and iterate over them creating the table yourself.
Most tables I've done could easily be written with this component. Most of the time I actually do something very close to its configuration objects, and then iterate over them with a `map` to create the `td` and `tr`. This allows me to separate concerns more clearly.
(I don't know about using css-grid instead of the old tables. Really, I don't know css-grid well enough.)
[1] The OP's let's you specify a custom renderer for particular columns. That won't solve everything, but will do for many cases.
I agree that these are the main issues with using this kind of component. However, most of the time there is no need to fork the component and, if you actually need things that the component doesn't allow, then it's the time to do it yourself. Because that doesn't always happen, if the component is easy to use it often is worth to go with it and only do the additional work if you need it.
> or the configuration expands to be its own little akwards DSL with very surprising edge cases.
This is the crux of the matter. However with this particular library, the configuration is extremely reasonable, simple and readable. It would be no problem to refactor the code to use the very same configuration to create your own table.