CUBE/vCUBE is not a true SIP proxy. It's a B2BUA. Think of CUSP as a load balancer. You don't normally want a load balancer to handle the workload itself, only to distribute load across a pool of resources.
CUSP, especially with Record-Route set to Off, is capable of handling a significantly higher Calls Per Second volume than CUBE/vCUBE is. It's actually more powerful than most people realize IMO. The documentation was just horrible. It took me weeks to figure out the first time - and when I finally did I was even more annoyed because it's fairly straight forward.
For those wondering: the nearest analogy I can think of is imagine CUCM if you had to define each number string/pattern first and then associate it to a DN/TP/RP/etc. The string has no meaning until you attach it to something. A lot of CUSP's config works like that: define the thing, then use it somewhere.
Here's a real world example where CUBE wasn't sufficient - even on the largest chassis Cisco offers. This will make more sense if you are familiar with the CUBE sizing deck and the various caveats around the CPS figures listed on the CUBE data sheets. The customer was implementing SIP trunks with a PSTN provider that supported a single customer SIP address per-physical circuit to that provider. The provider used a larger provider-assigned IPv4 prefix (e.g., /28) but their SBC would only send/receive SIP traffic to a single IPv4 address in that prefix. The call volume/load, based on actual SIP messages vs. the assumed 14 per call cradle-to-grave, and CUBE feature requirements were such that it significantly exceeded the capacity of a single CUBE chassis. We needed to distribute that load across a pool of CUBEs - but didn't want to pay for additional Ethernet circuits per-chassis. CUSP, with Record Route on, was used in front of that CUBE pool. Each CUBE also had an address from that provider's IPv4 prefix for RTP traffic but all SIP traffic flowed through CUSP. A single CUSP was easily able to handle that load.
