BGP - BGP Algorithm within confederations
First of all, it considers all routes within the confederation to be in a single AS. In other words, it doesn't consider BGP peerings between BGP routers in different sub-ASes to be eBGP peerings. It considers them iBGP peerings. This affects the BGP attribute that says that eBGP routes are preferred over iBGP routes. In such a setting, a BGP peering between routers in different sub-ASes is treated the same as one between routers in the same sub-AS as long as both are found within the same confederation AS.
For example, take a look at this diagram of a confederation with two sub-ASes.
Imagine that R4 advertises a route to its loopback address of 22.214.171.124/32 via BGP. It will inform R2 and R5 of this route. Both of these routers in turn will inform R3. If AS2 did not exist, and AS24 and AS35 were two normal ASes, then the tie breaker for R3 concerning which route to install would be to choose the route learned via eBGP over that learned via iBGP. That would be via R2 rather than R5.
However, in this case, we have a confederation of AS 2, so all routers are considered to be iBGP peers, at least as far as this attribute goes. So the route learned via R2 is not considered an eBGP route, thus, this tie breaker attribute does not apply. Thus we keep going through the attributes until we reach the "lowest router ID" attribute to break the tie, and the router (R2 or R5) with the lowest router ID will be chosen as the best next hop for that BGP route.