Replicas are for redundancy across servers, which in-turn may provide higher availability. The number of replicas directly correlates with the number of servers in a partition that may fail without bringing MySQL Cluster offline.
Partitions are to split processing across servers, which in-turn may provide higher performance. The number of partitions directly correlates with the number of servers that queries to MySQL Cluster will be divided between.
Let me see if I can make this clear. If you have two servers with two replicas, write performance might be reduced because the data has to be replicated. In both cases, with either a single replica or two replicas, read performance might be enhanced because there are two partitions (two servers) to split the query across.
MySQL Cluster does not provide redundancy of the MySQL Server front-end, so it is not an out-of-the-box, instant HA solution. You will need either application logic to locate an available SQL server, or you will need service monitoring / network logic to switch out a failed SQL server with one that functions. (You could also try installing the MySQL Server front-end directly on the application servers.)
Also, performance hits or benefits from MySQL Cluster will vary based on how your application is using the database, and what bottlenecks exist. Switching from local sockets to network connections will increase latency. Simple queries for cached data will bottleneck at the SQL server. On the other hand, some processing that is either bound by the processor or my disk I/O will benefit heavily. The best way to know the exact performance hit or benefit that MySQL Cluster will have on your application might just be to test it.