I am going to go out on a limb here, quite likely in a minority opinion, but here I go!
I avoid using them!
Now I notice your first bullet point mentioned:
Am I missing out on something, or are data driven patterns overrated?
Yes, to they are. I frequently have junior engineers approach me breathlessly when they discover it and show me what they've built and usually I shudder.
The very ironic thing is that part of my objection is that they actually can make it too easy to have tests! Yow. Let me explain: once you have that data table, it's extremely easy to start multiplying those cases out, often a good liberal dose of copy and paste starts taking place. Frequently you will end up with dozens of cases trying various combinations. For UI tests this can certainly start to make test suites slow and long running very quickly.
They also don't focus on specific examples and give quality detailed feedback about the issue.
I much prefer the BDD 'example' style where you have a full test example that runs and specifies exactly when the conditions, inputs and boundaries are, with appropriate language to describe the condition in simple readable language.
All said, I do think they have their place. I say avoid for UI and integrated tests. Use for Unit and some Acceptance tests but make sure that they do not have heavy or slow dependencies. For example if you have unit tests that mock and stub all dependencies and each one runs in 0.01 seconds then ok, a couple dozen rows of a data table driven test is ok. Just remember that a human still has to maintain and at a very minimum frequently read those lines.