Again your assuming.
For example, on average why would an office of 40 people ustilising a 16Mbps bonded services cause more load over the course of the month than 4 offices of 10 staff, each utilising a 4Mbps service?
Either way the average contention experienced on the DSLAM's backhaul is the ratio between the access (n x 4Mbps access ports) and the backhaul capacity. Bonding does not change this ratio, but upgrading the individual port speeds to 10Mbps does (dramatically).
For ordinary usage, I'd tend to agree with you, but the problem is there is a lot more bandwidth available on demand to a customer with 16Mbps bonding (not to mention the 40Mbps bonding proposed by this article which Mweb wishes to provide) than there is to each of those 4Mbps offices, and that's where the problem comes in: saturating a 40mbps line is a very different story for an exchange when compared to saturating an equal amount of 4Mbps lines but at different independent time-frames so that the sumtotal of bandwidth used by the individual lines on average at any given time is less than the sumtotal of a peaked bonded solution. Unless there is sufficient bandwidth overhead, this could be problematic.
Consider:
4Mbps Line at office A makes a full 4Mbps download from 10am to 11am
4Mbps Line at office B makes a full 4Mbps download from 11am to 12pm
From 10am to 12pm, the exchange not once exceeded 4Mbps despite two customers utilizing a full 4Mbps at different times. That's the basic idea behind contention ratios... and even though for practical cases the usages do overlap, you can still work out an average expected peak and then roll-out services based on that. It's exactly this expected peak which is disrupted by bonding, or as Profmerlin said: also by uncapped. With uncapped guys tend to download for much longer sustained periods, thereby pushing the expected contention ratio boundaries, because more lines are maxing out simultaneously (overlapping) rather than most being idle (larger free bandwidth pool); similarly, with bonding, these boundaries are pushed beyond what Telkom would have anticipated and provisioned for, and therefore at the end of the day customers experience an overall degraded service and the exchange must be upgraded to cope with the higher demand surges which may arise from just a few customers who now have this supercharged bandwidth at their disposal.
Let's say back in 2003 a Telkom exchange had 10Mbps overall capacity to serve a couple of 512k clients. This would not be a problem because the probability that all of those users will collectively reach that maximum download of 10Mbps simultaneously, is low (assuming there aren't too many, of course). If some of these clients were to bond these 512k lines to obtain say 4-10Mbps (but still having the same overall number of 512k lines to that exchange), then they could very quickly reach the capacity of that exchange by themselves (breaking Telkom's contention ratio expectations), so then the odds of reaching that 10mbps is increased because that improbable potential outcome is essentially made more probable by enabling a smaller group of users to essentially do so by themselves on demand. A greater backhaul capacity then needs to be deployed to counteract the higher probability->frequency of that bottleneck being reached. Now just scale that up a notch for 4/10Mbps where the exchange's maximum capacity is in the same basic ratio as the given example - the same applies...?
I've even heard unconfirmed reports that some Telkom exchanges offering up to 4Mbps DSL still today have as low as 10Mbps total throughput to the ESR. This is an extreme situation, but here a SINGLE user trying to get 16Mbps with 3 bonded lines would not even get 16Mbps, yet that exchange would cope fairly easily with even more than 3 independent 4Mbps customers, without them even knowing that their exchange is so limited/shared, because you'd need at least 3 x 4Mbps lines maxed out simultaneously in order to surpass that capacity - a much less likely event if you lower each user's maximum throughput (and then you can in turn provide more users with a service).
So my 'assumption' does seem justified in that it's based on interpolating potentially likely outcomes in reality ;D