Please mind that there are no benchmarks yet and this page describes the properties as I expect them.
Number of nodes Due to the zero administration building small networks should be very easy. The per-route overhead in cor will likely be higher due to the way route discovery operates. In the end, you have to multiply that with the number and accuracy of routes you want to have and their change rate.

In mesh networks do not scale well if you connect to distant nodes anyway. Otherwise links have to be shared with lots of other nodes which limits the bandwidth for each of them. In this case you should probably worry about more user traffic than routing overhead. If you only want to establish an internet connection, you can stop searching as soon as you find a good uplink.

If you want to build an internet, you would have to "compress" the routing table. The trick is to break the flat address space up. You only need one routing table entry for each organisation that forwards traffic for others. When you want to connect to an end host, you need to know at least one of the networks it is conneced to - some as with ip networks. However, I doubt that something like this will happen anytime soon and I do not put any effort into this.
Number of connections This is a point other people seem to be concerned about a lot. Cor will not scale in this direction as good as ip. But I am not too worried about it in particular. Memory has gotten much cheaper in the last two conturies and I do not think that the number of parallel connections has increased to same. Also, in a mesh network you typically only need one or maybe a few connections to internet uplinks and a few for route discovery. But if you want to build an internet, then maybe you should worry.
Link speed Cor has a low per packet overhead, can resize the packets dynamically and has a QoS/credit system. All of this should help to use low to medium line speeds efficiently. On the other side, the way routing discovery works might limits on how low bandwidth can get. The main limit here is the router CPU performance. Linux IP software routing speed is currently limited to a few 10 gigabit links on fast machines. I did not do any benchmarks with cor yet, but I guess that it will be considerable slower.
Latency When the load is low, cor will probably have a somewhat higher latency than IP. But when there is high load, the QoS/credit system should be able maintain a low latency for connections that need it. Cor should be able to handle high latency and loss way better that IP due to link local retransmissions and absence of congestion window.
Loss Cor does link local error recovery for every link, possibly causing higher cpu and memory usage than necessary. It should be possible to make this optional, but I do not have any plans to do so.
Broadcast domain size Due to neighbor discovery and constant pinging between neighbors, there are many more packets on idle networks than on IP networks with most hosts having a "static" route via DHCP. The number of unicast packets on the backbone grows O(N^2) and the number of broadcast packets grows O(N). However, switched networks should still be able to handle a few thousand nodes. It might be a problem for some wireless networks and for devices which should not wake up too often due to power usage. An easy way around this would be to configure clients to connect only to routers, but not to other clients. But then all traffic will go through one of these routers.
Device hardware I guess that the hardware requirements of cor will be higher than IP, especially if the device is a client and needs to run a routing daemon. In some cases it might also be necessary to run IP and cor in parallel. Internet uplinks will need to run as gateways, not as simple routers.