Recall that routes received by a route reflector from a route reflector client are advertised to all clients and all iBGP peers because the client is assumed not to have a full mesh to the iBGP network. In a route reflector cluster you will have route reflectors that have a normal iBGP relationship and they will both have the same clients, so they will receive iBGP updates from the client and from the other RR.
There are also cases where you may have RRs that are clients of other RRs for scalability reasons (this would be a very deep network). In this case you would also need the cluster ID for loop prevention as the RRs are reflecting the same routes many times and it's important to recognize when the routes are being reflected in loops - as will certainly happen.
If you configure the RR peering with the router reflector client, RR will send updates to each other. This is a ibgp peering, but the rr client configuration overrides the dont advertise to ibgp.
Under ebgp, the as path is used to detect loops. But for ibgp, the as path remains the same under the same AS. So bgp needs other way to detect routing loops.
If you dont need the RR to exchange prefix, because these are not redundants under your topology, ther is no loops, then dont need to configure RR as rr clients each other, dont need peering between them, and dont need the cluster id.
But both RR have to be connected to every bgp router in your network. And if a RR lost its connection to a peer, will not learn its prefix through any other ibgp peer.
Under a redundant topology, or where one RR have some peers, and other RR other peers, you will need the cluster id, and RR should be rr clients each other.
Think you have a triangle, 3 RR with different ibgp peers, each RR have to be rr client of the others RR, if not all peers will not have the same bgp table.
If a path between two RR goes down, then they could use the other RR as a backup path.
In this case there is a RR loop, the way to detect this is the cluster id. If not every ibgp route will be propagated from rr1 to rr2 to rr3 to rr1 to rr2 ....because they are rr clients. The cluster id breaks this loop, because when a prefix have the same router's cluster id, then routers checks if the received prefix has been originated by the router itself. This way detects the loop.
So under a redundant topology and a rr loop, you will need the cluster id and RR should be rr clients. If you dont have a redundant topology, you dont need.
Without cluster id there is no way to detect routing loops under ibgp, and this should be configured manually because in large scenarios you could have several rr "farms" and have several cluster id, confederations, etc.