We did not implement includes.
After theory-crafting out scaling issues, it became apparent we would need to paginate includes if we returned them... BUT we would also want to have a mechanism for allowing to specify what "page" we are paginating each includes on and return them properly. This was a pain in the ... well you know. It also came to our attention that if we did paginate the includes, some partners may assume the includes we would returning are all of them, not just a subset.
Because the spec does no specify how to do this completely, we decided not to implement includes. (includes are not required for spec as far as I can tell). This does mean partners must make more requests. But the up side: we can limit the number of queries per request to a manageable number and keep response times sub 100ms.