ECS is commonly described as "data-oriented", not "data-driven". It's confusing, yes, but the have separate and unrelated meanings in the game development space.
The former is a methodology for building engine systems that are cache-friendly, the latter talks about workflows that are more flexible to artists and developers.
You can use ECS without "being data-driven", and you can use data-driven workflows without ECS.
> You can use ECS without "being data-driven", and you can use data-driven workflows without ECS.
True, I've read about ECS being used for one or both of those purposes.
My first contact was ECS was as a composability pattern. So, in a "high level" purpose, as an alternative to inheritance. It was also described as "Game Object - Game component" pattern.
There's the "performance" ECS, where it tackles data locality.
And the "game element definition and configuration" ECS, where it solves a high level problem of building game elements. On the "game developer" level, Unity works like this.
It's all about having configuration data separate to the logic. And use this data to setup and build the game elements.
Here's a couple of videos I created:
How to start with Data Driven Development in Godot: https://www.youtube.com/watch?v=ZG__fXSp74c
What I can do with it in my game, One Way Dungeon: https://www.youtube.com/watch?v=PqZwKahZ3cU