There, now that we got that out of the way, lets talk about why. There are two main differentiators when it comes to ExpressionEngine fieldtype add-ons: those that save their data in the native exp_channel_data tables, and those that do not. When it comes to interroperability between add-ons this is usually the defining factor of makes them "play nice" with other fieldtype add-ons. When an add-on chooses to save its content in its own database table, usually a necessity driven by the fieldtypes complexity, it is removing itself from ExpressionEngine's sphere of knowledge (for the lack of a better term). EE knows about the add-on because it is installed, and the add-on can talk to EE because of the excellent code hooks and events that are in place in EE's core, but when it comes to saving and retrieving data (usually a channel entry), EE itself does not know how to query the data from a fieldtype that saves its content in a separate database table. The fieldtype add-on is soley responsible for doing that by using the hooks and events EE provides.
There are two native ExpressionEngine fieldtypes that save their data in tables other than the exp_channel_data table, and those are the Grid and Relationship fields. Third-party fieldtype add-ons like Bloqs, Matrix, Playa, Channel Images, Channel Videos etc also save their content in custom tables. Now imagine the scenario where two of those add-ons are designed to work together. Or more specifically where one of these add-ons lives inside of the other. Here is a common scenario:
Bloqs → Relationship
Managing Relationships inside of Bloqs (or Grid) isn't all that difficult. It takes some trickery to get it to work, but its managable. Now lets look at a more complicated scenario:
Bloqs → Grid → Relationship
If we introduce a Grid inside of a block, and that Grid can have 1 or more rows with a Relationship field, the complexity skyrockets. We're making sure data is passed correctly through 3 layers of add-on code, and into 3 or more database tables, and this is just for the data side of things. On the front-end, what if the related entry then contains its own Bloqs field, that in turn contains another Grid, which in turn contains yet another Relationship.
Admittedly, this may be technically possible to pull off, but there is an important, and often overlooked aspect, of developing and releasing add-ons. Supporting add-ons is no small feat, especially when they are complicated, and are meant to work with other third-party add-ons. There will be bugs, and the more layers of complexity that are introduced the number of bugs will increase. While initially adding what seems like a simple feature may take only a few hours, or a few days, supporting that feature will last for the lifetime of that code.