ISDN is 16 KB/s symmetric. The 50-100 kB share limit in adversarial conditions would be around 3-7 seconds on ISDN. Your advocacy of a 100 kB share limit seems to me like you're trying to protect people mining with ISDN, or maybe 1st-gen ADSL. You know, the speeds we had in 1999.

By the way, the relevant metric for adversarial conditions is download bandwidth, not upload.

You don't have to upload other people's shares in a timely fashion. You only need to upload your own shares quickly. Adversarial conditions don't apply to the shares you upload yourself. The existing code will send the transactions in a getblocktemplate request to peers as soon as you start mining on them. The peer will usually have received all of those transactions before you find the share, so you usually only have to upload the hashes for those transactions. For a share that adds 100 kB of transactions, that's expected to be around 8 kB of hashes. Again, ISDN spec.

However, an adversarial entity could modify their p2pool code to NOT send transactions out in advance. Doing so would substantially increase their orphan rate, of course, but let's say they want to do it anyway for selfish mining purposes. In this case, they could make a share with 100 kB of completely new transactions, and they would make you download that 100+8 kB ASAP so you could switch to mining on top of it. Until you get their share from them, your mining would be competing with theirs, and you would possibly end up orphaning their share (or they yours). That might take 650 ms if you have 1.5 Mbps ADSL, or 6.75 seconds if you have ISDN (suboptimal, but potentially tolerable for short periods).