You can have more test coverage because while you are creating the data file you will  have a better visualization of what have you already included and this will help you to identify if you are missing any test scenario.
Scripts and functions can be reused in different tests and also be combined with multiple data files which give us a wide variety of test scenarios with less test scripts.
Test scripts will run faster because  most of the time with one single test you can cover positive and negative scenarios by just changing the expected result in our data file
Maintenance of our test scripts is easier, because if we are using one scripts which is testing both positive and negative test cases and there is a story in the future which implies that a field is no longer required, instead of making the changes in several scripts we only change one script and remove the field form the data file.
Data setup required for the test execution can be also included in your data file and created inside your test script.
And the more important reason for us is that there is not hardcoded data in your test scripts, since you have the test data in a separate file. Changes to the scripts do not affect test data and vice versa.

The easiest way to visualize your data file, if you don’t know where to start, is every row/payload  from your input data file will be map to a test case. You can add a row/payload with the data required for every test case that you will usually create. So, if you have one test script that is using a CSV file with 30 rows you will be testing 30 test combinations with a single script.
Add every element/attribute/field  as parameter, so you can use the same data file for several test scenarios.
Use element/attribute/field names related to the parameter you are going to replace so everyone who is checking your script understands it.
In case of API testing If you have a field that is an array, add a field for every element you will add in the array  including the comas, so you are not forced to always enter the same array length.
In case of API testing if you want  to cover scenarios like validating the response code 404 or checking Authorization header , you can add an URL field so you can test the response code 404 and a field with the Authorization so you can test as many combinations as possible.
Use a field to describe your test scope, so you don’t forget what that payload or line was for.
Add a field with the expected result. It can be a response code if you are testing an API or the text of a message if you are testing UI. If you do so, you can have both positive and negative tests in the same data file.

The first try was using Jmeter (which we are using for API Testing and Performance test). We started using it for REST API testing because there is a lot of documentation on how to use it, it is simple to use, easy to learn and it has all these “plugin controllers” that can be used to create your script.  So, by using the CSV controller you can create a script using parameters and with a single script test positive and negative test in most of the cases. The only cons that we found were that if your payload is big is not that easy to visualize your CSV data file and you need a tool to separate the field by columns because if you try to use a regular text editor it can become a nightmare (and sometimes even with the columns you have to scroll your window).  I also use a column for the test scope, so you can remember in the future what was the intention of that test.
Since our brand-new project also has a UI and is developed in Angular then we started reviewing Protractor which was designed especially for angular and uses Webdriver and we were already familiar with Selenium. I created some test scripts and the transition from Selenium to Protractor was smooth and  it works very nicely and started designing our test using a JSON file as our data input adding all the required fields for ou test scripts and also a field for the test scope so we don’t forget what is the test intention of the payload (Recommendation when using protractor to make your scripts easier to maintain separate your page object from your spec, and create a helper file that contain all the functions required to your script to run like click, add text into a text field, function to read the data file, etc.)
In my experience I like using JSON files rather than CSV files as data files, at least for me it is easier to read, it looks cleaner and more organized.
For these reasons I wanted to try another tool to create REST API test scripts using JSON files so last year I attended to the automation Guild and there was a conference about Inuit Karate, which is kind of new, it uses Gherkins syntax, so it is not hard to learn, and I wanted to give it a try. I started creating integration tests and I like it because with the JSON file my data file looks clean and with the Gherkins syntax, code is easier to understand.
Besides the already mentioned tools we  have also created some other tools based on a data driven test design pattern. We have some python and java script for example one to analyze the test results based on a CSV file or another to create JWT tokens based on a JSON file.