Routing slots aren't the only resource you're consuming. In general, many of the prefixes coming out of a given AS have common attributes, e.g. path, MEDs, etc. Those attributes are stored only once (at least in the BGP implementation I know) even if they're used by hundreds of prefixes. If you attach a new leaf AS, it must, by necessity, consume another one of those slots. If the customer prefix were announced by the upstream, however, it would not require an additional attribute slot; it'd reuse one of the existing ones.
Now, I'm not aware that there's any serious shortage of attribute slots like there is routing slots, but there's no sense wasting them if there's no gain to be had doing it. Save your (and everyone else's) RAM for more prefixes.
I think that this deserves a bit more explanation... Most implementations use an "attribute cache". An entry in this cache typically consists of a set of different attributes. Which attributes constitute a cache entry is entirely up to the implementation. Each prefix will have a number of paths. Each path will point to an attribute cache entry and also contain one or more other uncached attributes. Individual attributes themselves may also be cached. The primary attribute cache may or may not include the AS path. If it does not, it is very likely that there is a cache for the AS paths. Again, this is all implementation dependent. If an implementation does cache AS paths independently from the attribute cache, then the cost of a stub AS is only one more AS path entry in the AS path cache. If an implementation does not cache AS paths independently, then creating a stub AS will create a new attribute cache entry, complete with AS path. Regardless of this, it should be noted that this is only using BGP table RAM. This should not affect the main routing table or the forwarding table. Having an additional PI prefix in the first place is the expensive part, as that does consume BGP RAM, routing table RAM and forwarding table entries. IMHO, wasting any resource is unfortunate, but the cost of additional forwarding table entries far outstrips the cost of additional DRAM. Thus, adding an additional prefix does merit a significant shout from others, but the stub AS should only be an incremental whimper. Regards, Tony