Building a representation of a bug takes several database requests to get the bug's tags, permits_expiration, can_expire, and is_complete. This is especially bad because permits_expiration, can_expire, and is_complete all make basically the same query: one that gets all of a bug's tasks. This leads to a lot of database queries when getting a collection of bugs.
As a temporary measure we've removed permits_expiration, can_expire, and is_complete from the bug's representation. There are two long-term solutions we're considering. The first is to show a stripped-down representation in collections and expect clients to follow the self_link if they want more information about an entry. The second is to populate behind-the-scenes caches so that an entire page of bugs can have their permits_expiration, can_expire, and is_complete populated with a single database request.
This is a special case of a larger pattern which was discussed recently on the -dev mailing list: object iterators returned by the API collection code trigger many potato-programming behaviours, generating many hundred, or thousands, of DB roundtrips. So possibly this should be generalised and raised in priority.