There are several reasons for not chaining switches, all of which relate to performance with the parameters effective throughput, resilience, latency.
As Ron has aptly pointed out, more aggregation means more bandwidth competition - all users behind a core switch port compete for the bandwidth of that single port. In another perspective, the longer a potential path in your network is and the more ports are involved, the more total bandwidth is bound by a flow along that path. To keep paths short, a tree is a better approach than a chain.
Some might argue that latency increases when more L2 hops are necessary - while this is true it only becomes noticeable with longer chains. A gigabit switch has a forwarding delay of at most 10 µs (usually much less), so for a chain of 2 or 3 switches it doesn't matter too much unless you're running very latency-sensitive applications.
Additionally, chaining switches introduces more single points of failure and increases their impact - if reliability is a concern. When a middle switch or its link fails, all switches and users behind it are separated from the network.
Most often, there's not only a single deployed cable from the core cabinet to the next. So, use those to create direct links to the core from more remote cabinets. Instead of chaining the switches, try to cross-patch a remote switch, so that it can connect directly to the core.