When we talk about the length of a cable, we mean the length of each individual conductor, not the sum total of the lengths of all of the conductors in the cable.
In our case, this number is close enough to the the length of the whole cable as measured from end to end that we can get away with using one number here, but some cables, such as Cat6, use twisted pairs of conductors, so the length of each copper wire is actually a little longer than the cable itself. Again, not a huge deal for Tessel, but good to keep in mind.
In this case, I mean the length of each cable attached to an Ambient Module can be 7m. The maximum allowable combined length of all cables connected to Tessel depends on the communication protocols used by each module more than anything else.
In brief, if you don't connect pins which are not used by the module to Tessel (read: only include the wires you need in the cable; check the design files to see what you module(s) need), you can probably get away with using a longer cables.
See the section below on signal propagation for more.
Here's some of it, distilled a little. Anything I missed will make it into docs eventually (bug me if it doesn't) in an effort to save you hours of crawling Wikipedia.
These turn out to be the most likely limiting factor due to the prevalence of 28 gauge ribbon cable.
The 7m length I gave is a worst-case for a cable that uses thin wires (28 gauge, specifically) and draws a lot of current (100mA). The length restriction in this case comes from resistive losses in the cable, which, in a 7m cable with 28 gauge wires found in most cheap ribbon cable, would total roughly 0.3V (keep in mind that the current must flow to the module and back, so twice the length of the cable for twice the loss). This means that module on the other end of the cable would only have 3.0V to power itself, which may not be enough.
This online calculator is what I used for generating these numbers.
Note that 0.3V of drop across a wire is horrendous and should be avoided at all costs. Using lower gauge (thicker) wires mitigates this significantly. It's also worth noting that, because the voltage drop is proportional to the current being conducted, the Ambient Module's nominal 10mA draw will produce a drop that is roughly 10x lower (good!) than what I have described as the worst case.
Takeaway: Resistive loss matters more for higher power modules than lower power ones and thin wires are bad.
As wires get longer and loopier, they become more inductive, which causes an additional voltage drop as the power draw of the module changes with time.
This is the reason we don't advise powering motors off the GPIO bank. The coils inside a motor are highly inductive, so quick accelerations will cause spikes on Tessel's power supply which could destroy the device.
The GPRS module should never be used with an extension cable unless it is powered externally for similar reasons. Lots more in this blog post I wrote a while back.
Takeaway: Cable inductance matters more for modules that use power in bursts, such as anything that transmits (GPRS, BLE, IR, etc.).
Longer wires don't carry high-speed signals, such as SPI and I2C, all that well. The reason I cite the current firmware on the Ambient Module in my reply is that it includes a set SPI speed at which the Ambient module communicates. It turns out that this speed is really slow (1kHz) and is not the limiting factor here, but ultimately it could be: the SPI controller on Tessel can run into the the 10's of MHz range...if the SPI device listening supports it and the cable can carry a signal that fast.
The nastiest reason that cable lengths should be kept short is signal reflection, which gets worse as cables grow in length, reduce in quality, and are improperly terminated for a signal at a given frequency. This is all theoretical, but the worst-case scenario has any given signal bouncing around all available paths until it terminates, which puts a restriction on the maximum combined length of all conductors attached to any given bus.
Takeaway: Signal propagation is the hardest to estimate/model and will typically only be an issue if you have lots SPI/I2C modules on long cables.
Physical metaphor: Imagine trying to listen to a rapid series of clicks in a very echo-y room when you're not right next to the clicker.
Case study: SPI
Because the SPI bus is shared by all the module ports on the board, the sum total of the lengths of the cables connected to the SPI pins limits the maximum allowable SPI frequency. Unfortunately, control also runs the other direction: some modules, such as the Ambient Module, include firmware which dictates an expected SPI speed, which means that cables can only be so long before you would (theoretically) start to run into signal propagation-related problems.
Reflection would come into play if there were, say, three I2C modules and one SPI module connected to Tessel, all with long cables. The SPI signal could theoretically bounce around to each of the I2C modules (which don't terminate the SPI lines) before reaching the SPI module. The SPI module would get a series of copies of the signal, each delayed by some amount of time, which could make it hard for the module to interpret the signal.
Note that these limitations are rooted purely in theory and have not been tested on Tessel. Translation: you should experiment to see what actually works because, well, Einstein said so.