There is effort in creating a queue. A tiny amount of effort — one line in a while loop. And there is also effort in reading and writing a CSV. There’s always effort, of course. In this case, I suggested redis, so that would need to be installed, which is also a tiny bit of effort.
There are going to be two processes whether we use CSVs or a queue, and either could fail, as could the entire machine or its power supply. No-one specified robustness, but a degree can be presumed. So, sure, there are failure cases, but I see no significant difference between the two cases.
So, I’m not disregarding robustness as premature optimisation, but it’s not a priority. If robustness was a priority, we’d likely not use a pi. YMMV
The implementation I suggested is a queue, but it’s also FIFO. Though, since there is only one producer, it doesn’t really matter.
One additional point, if loss of the tweet message were acceptable on failure of the machine (we don’t know), then the queue solution could run entirely in memory, thus requiring no disk management or maintenance. It would just work, unless it didn’t!
As you suggest, if we are likely to be doing more stuff with this system, a more flexible solution is preferable, and the queue idea is better.