I guess if you're more comfortable with that, then perhaps yes, a CSV dataset would be better for you and it would make no difference for your use case. But for me, I could say the same: that with CSV I'd have to learn how to import it into an SQL database and figure out exactly what to JOIN because it's not a graph but a relation db made of tables.
So it really depends on what you're used to. But RDF adds more to the table really. Things like URIs for identifying things which could be directly deferenceable (if HTTP URIs). So you know what your columns actually mean and they're not simply a string of letters. And you'd know what it's in your cells and exactly what type of data it's in the cells.
These are important features that make data integration a lot simpler imho. But if you're used to CSVs and don't care to make your workflow more efficient with the features RDF offers, then I guess you're better off?
Also please check out this interesting answer by Jarven: http://answers.semanticweb.com/questions/19183/advantages-of...
Consider: I want to use data from two sources. Do I spend months not working on the hard part of the problem — reconciling the different data models — because I'm learning how to use RDF, configuring, fixing and tuning a bunch of niche tools or do I just pick one of many database options which have much higher performance, are well tested and highly durable, have great documentation and language support, and simply JOIN two tables (classic SQL) or add a namespace in a document (NoSQL or hybrids like Postgres)? Unless you're in one of the few semweb shops, you need to have a HUGE amount of disparate data for that not to be a grossly uneven trade-off, which should not be the case.