I'm really not.
There is no need to turn off redis' persistence.
See above. I use this approach all the time.
This isn't over-engineering. A powerful tool is fine when it's simple to use (and, as in this case, has a negligible overhead). No-one's suggesting rabbitmq or even AWS SQS.
That also solves the initial problem, both simply and elegantly.
My tag line is: obsessed with simplicity. As I mentioned earlier, I regard the CSV solution as more complex.
My day job is, basically, helping businesses get out of the mess they've created. Typically, a business that has become successful without any focus on the quality of their software (by which I chiefly mean maintainability) and that now finds itself painted into a corner (where the limiting factor has become the ability to adapt their software).
After lack of tests, the biggest problem I encounter is home brewed solutions to problems that have grown out of all proportion to the original use and on which the whole system depends. You probably know the rest of the story: no-one knows how deep the rabbit hole goes, and no-one want to touch it.
On that basis, when developing, I practice a kind of "YAGNI, but you probably will". If the overhead to provide vastly more flexibility and functionality is very small, then it's worth doing from the outset.
I should add that we are considering redis here, which I regard as ubiquitous nowadays.