Redis can be scaled using replicas and shards. However:
Based on these facts, if I'm not interested in HA does it make sense to always use shards and not replicas since I get the benefit of scaling both reads and writes, with a smaller memory footprint (and lower costs)?
Yes you can.
About HA, you have to be sure you define/know what is the application behaviour if this shard is becoming not available. (dataloss, service unavailable, ...)
On the replica-read, without having information about your application it is hard to tell; but most of the time a Redis instance (shard) is enough to deal with lot of load. A very "short" rules is, that a shard can deal with 25Gb of data, 25.000 operations/seconds with a sub-ms latency without any problem. Obviously this depends of the type of operations, data and command your are doing; it could be a lot more ops/sec if you do basic set/get.
And usually when we have more than this, we use Clustering to distribute the load.
So before going into the "replica-read" route (that I am trying to avoid as much as possible), take a look to your application, do some benchmark on a single shard: and you will probably see that everything is ok (at least from the workload point of view, but you will have a SPOF if you do not replicate)
