Yea, I can't see why - I'd have to read the I2C specs again, but I think any device to meet the 100KHz, 400KHz specs would have to be able to sink some given amount of current for a bus length of X....
So yea, it's weird that it ended up being 100Kohms.
Anyone know how many devices are on the bus? I can only think of 2.
Damn, all the skeletons are coming out of the cupboard now

Yeah, this should have been 10k (or even less). We didn't own a scope at the time this was designed hence the issue was never actually seen (ie we never looked at it, and the original software had very long bit delays in the i2c driver). To mitigate at least part of the problem, we have a shorter delay if we're sending a zero bit.
edit: At least, that's how I remember it. Did you see that in the code, Mark? Really, adjacent 1 bits being sent in a row only need a delay for the first one too.
Once some units had shipped with this then it was kinda not worth fixing - that and we didn't really do anything that was very urgent on i2c throughput.
The 100pF caps were recommended by Philips to reduce any audio coupling from the falling edges.
Hugo