Simplest upgrade data from ElasticSearch 2 to ElasticSearch 6

I've discovered after much suffering that the best way to run elasticsearch on a single server is to change the default setting of:

index.number_of_replicas: 1

to

index.number_of_replicas: 0

If there are 0 replicas, elasticsearch will never try to assign shards to any other "replica" then itself, thereby removing the issue of unassigned shards and corrupted indices.

My full (stable) standalone, non-default elasticsearch config is:

node.max_local_storage_nodes: 1
index.number_of_replicas: 0

Note, this is a config for a log-reader setup only, not a full scale production setup.

Is it ok to run the curator job on the client machine as we have done?

Yes, since the "client" machine isn't doing anything except firing REST requests at your ES cluster and waiting for the response.

Is it ok to take the snapshot of all the indices from a single machine?

Again, yes. For the same reason as the first question.

Since the logs are pushed continuously will it make the cluster unstable when snapshot creation and pushing to Amazon S3 is going on?

According to the ES docs on Snapshot And Restore

Snapshotting process is executed in non-blocking fashion. All indexing and searching 
operation can continue to be executed against the index that is being snapshotted.

There might be a slight slowdown in the indexing rate, but based on your machine specs, I would think it's probably going to be fine, but there's really no way to know unless you try it. The limiting factor for speed of the snapshot is likely to be disks for a shared file system repository, and your Internet connection speed for S3 repositories.

In terms of using an S3 repository and how that affects the process, there's not too many details (as in, none) in the docs for the S3 Repository plugin as to how it actually works. I suspect that each data node holding a primary shard would push it's shards to the repository, S3 or otherwise. This means that there's likely not going to be any more load on the ES cluster when performing snapshots to an S3 Repository than there would be to a shared file system repository.
Again, TEST IT, since each environment is unique and what works for one person might not for the next.

What are the best practices people generally follow for backing up old indices from Elasticearch?

I find that ES has quite good documentation, and there's a section on Snapshot And Restore. There's not actually much in there in terms of "best" practices, so unless you come across some other sources online, I'd say your best bet to just start trying things out to see what works for you.