It is not common to have one parameter file for one project unless you have less than 20 to 30 workflows in the project. It is usually split based on the business requirement, for example based on the geographic locations of the business or the business units or the OE’s.
There are also cases where there are individual parameters created for each workflow and all of these are deployed as well. Yes, this is a strenuous process and if you have global variables defined then you have to add them to each and every file along with the workflow specific or stand alone parameters.
Which one is better, would actually depend on the total number of workflows available and the number of times the deployments are arranged.
Even if you have the weekly releases, once you define a parameter file with all the standard global parameters then from the next time on wards it’s always the updates or the new parameters.
If there are individual parameter files defined then instead of deploying the parameter files based on workflow you can have the complete folder deployed. Or as an alternative you can have a script created which will verify the changed date of each file and take only the ones which were impacted/updated from the last deployment cycle.
To extend it further, you can also have the script to verify the content of the file to see what are the changes and add them to the log file and send it as a report post deployment with proper back ups.
So, it all boil down to what works for the project with less resources and zero errors as parameter files are usually handled manually and there will be mistakes when there is any manual interventions.