You may use the replica two pool for backup but never use it for production data without a backup. Ceph does light scrubbing daily and weekly deep scrubbing. If inconsistent PGs errors are found during the scrubbing, you can easily repair the error object by comparing it with other replicas. However, if you are using a replica two pools, you have a high possibility of lost the object because you don't know which replica is the correct one.
A not so uncommon situation where this could occur is if your OSD's are flapping. Once the cluster stabilizes, and both disks are back online, they've each received different writes, and there's no way to turn them up. The only way to combat this scenario is to have a quorum, which means three or more replicas.
If you can not suffer data loss and want to save costs, you can choose the erasure code pool. Erasure code pool allows more concurrent drive fails at a lower cost. An erasure code pool with a k+m=4+2 profile is safer than replica 2. Because EC actually writes less data, it is sometimes faster than replication for writes, but slower on the reads due to the requirement to reassemble the data from multiple nodes. The major drawbacks of erasure code compare to replica 3 is that EC pools take longer time for recovering failed disk. You can test the erasure code performance with your real workload before you put it into production.