In general I always recommend to use a proper AMQP implementation with Celery and not Redis. If you're not willing to use something like RabbitMQ then that's less points for Celery. That is less point because SQS lacks some for the key components that makes Celery an interesting alternative to implement stuff by yourself.
Celery it's just a task queue framework that uses an AMQP library written specifically for task queues (kombu) and a connection pooling library (billiards). It implements a basic structure for workers and producers so you don't have to worry about it.
So, if you are going to have some heavy loads on production Redis is out of the question. You're only left with "should we use Celery with SQS". And you are not going to do anything complicated like workflows. The only thing Celery is bringing to the table is:
1. An abstraction layer that will manage SQS queues for you, which is good since your code can be migrated to, say, RabbitMQ in the future without a hassle. There's other options like ZeroQ and others...
2. Basic worker implementation with re retries, throttling, class based workers, etc... Some of this is already bedded in SQS like retries, tho.
3. The biggest thing Celery brings to the table, I would say, is a result backend implementation. You can save the tasks results or just metadata to implement monitoring or anything like that.
Flower is OK for monitoring but it's not 100% perfect and it might fall short in production (we need more support on this side). But, with Celery's abstraction layer it's easier to implement some custom monitoring, e.g. using class based workers.
I can't tell you weather to use Celery or not because I don't have enough info on your project but I hope this sheds some more light into the issue. Anything that's in Celery can be easily developed in-house, mainly since we're not talking about the more advanced features. I think the tie breaker would be to do a proof of concepts of both and try to decide which is going to take less time to get running.