Appropriate shard allocation setting for rolling deployment without cluster functionality loss


I am interested in performing rolling deployments of Elasticsearch where the cluster does not lose any functionality during the deployment. The official Rolling Deployment Documentation says to set this transient setting:
"cluster.routing.allocation.enable" : "none"
but while this settings is applied users of the cluster cannot write any documents to newly created indices. Newly created indices also put the cluster in a red state which can be a problem when using the cluster health status to automatically orchestrate when the next node can be deployed in a rolling deployment.

For my use case setting the shard allocation setting to new_primaries instead of none seems appropriate.

Are there special performance concerns with using this setting for rolling deployments that led Elastic to recommend setting shard allocation to none instead of new_primaries? From my understanding it seems like there's no downside with the new_primaries setting as the new indices will not have data stored on the Elasticsearch node that is offline and about to return.

I am also interested in the difference between the primaries and new_primaries setting. Even with the shard allocation set to none Elasticsearch will promote replicas to primaries when the primary shard for an index is down. In what situation will setting shard allocation to primaries be different than new_primaries?