@wordpress/dataviews is the list-and-grid interface core uses for its own data screens, and it has always been the obvious answer for a plugin that needs a filterable table of things. The obstacle was never the API. It was that bundling the package meant shipping code that reached into core's private APIs.
That dependency is gone.
The failure it removes
The old failure mode was not subtle. You bundled a version built against one core version, a user ran a different one, the private API had moved, and the result was a runtime error in the admin. On a site you could not reproduce, triggered by an update you did not control, reported to you as "the plugin page is blank".
The alternative was to not bundle and instead use whatever version core happened to expose, which meant your interface changed underneath you whenever WordPress updated. Neither option was good, which is why a lot of plugins have a hand-rolled table component that exists for no better reason than this.
Components that got public addresses
Several pieces previously reachable only through the private export now live somewhere you can rely on. Calendar, RangeCalendar and ValidatedInputControl are in @wordpress/ui and @wordpress/keycodes.
A fair number of plugins were using those through the private route, because the alternative was writing a date picker from scratch. Update the imports now, while the change is trivial.
The pattern behind it
This is the third or fourth change this year where something the editor kept behind a private export has been given a supported home. Individually each is minor. Together they are the extension surface widening deliberately.
Which is an argument for a habit: every few months, go and look at the workarounds in your own codebase. A surprising number of them exist to route around a problem that has quietly been fixed, and you are still paying to maintain the workaround.
