When the coinbase transaction is full (beyond the size that some mining hardware can handle without a performance penalty... mainly poorly coded or low memory embedded miners) a few ...
Can you share the exact size, please. I am working on a low memory embedded miner and don't want to have it classified as poorly coded/developed

. It's easier and better to plan for more memory, than extending it latter
The generation transaction can possibly be as large as 1 MB, which would requires hashing the full 1 MB per 4 Gh.
Actually meeting this requirement turns out to be pretty difficult with modern hashing hardware, even with a dedicated high end PC, so I guess just "do your best" - it is possible (but not implemented yet) to use a midstate to optimise this if the extranonce is at the end of the generation transaction.
A good test would be to run BFGMiner with --benchmark-intense mode.
You should probably read
https://en.bitcoin.it/wiki/Mining_manufacturer_tech_guidelinesBasically a low memory embedded miner is probably the worst possible thing to make as a miner at this point. It's cool to have them be independent of a PC I suppose, but hard coding mining protocols and the like is just a terrible idea. These things are not going to stay the same forever, and the companies and designers that take such shortcuts will have incapable hardware at the end of the day.
Eligius's generation/coinbase based payouts are definitely here to stay, and I'm sure eventually other legitimate pools will adopt this practice in the future as well since it prevents the pool from ever having any significant amount of miner funds on hand in the event of some type of compromise, for one, and also prevents any real theft/loss from being possible in the event of a shady pool operator doing the wrong thing. In my (probably slightly biased) opinion, pools that won't even consider it probably shouldn't be trusted with your hashes... but that's just me.