I hear you. We designed the form attachment functionality the way that it is because we learned from Aggregate users that both forgetting to attach expected media and attaching superfluous media were problems (Aggregate just let you attach any files you wanted). With Central's more structured approach, those mistakes are impossible.
Generally, when folks want to attach CSVs that reference media, the CSVs really represent lists of entities that have some broader lifecycle in their project so we'd like to address the media need at the entities level. That would mean we could, for example, have media captured with one form automatically available in other forms representing other workflow steps.
I was asking @Prashant_K about reasons for wanting to use an external file to get at whether they are aiming for an entities-like workflow: are they generating the CSVs programmatically, updating them over time, etc.
Currently, Central parses the form definition, creates attachment slots based on that parse, and only accepts files that fit in those slots. I don't think it would be straightforward to have it accept arbitrary attachments and it's not something we would want in the core.
If you're attaching media programmatically, one (possibly terrible) stopgap idea would be to have a dummy list like @ahblake described and to use filenames that are <row number>.jpg. That way the form definition never has to change, even if the attachment does. Let's say you know you'll have at most 20,000 of them, you'd have 1.jpg, 2.jpg... 20000.jpg. To make things really explicit and to support row deletion, I would include a column in the CSV with that numbering. When you update row 3, you'd attach whatever corresponding image as 3.jpg and so on. That would allow you to reuse that same form and dummy list even as the "entities" change.