I think it is not a case of one versus the other. I think indexing all user text content is quite important but totally agree with @Oshyan that as the databases grow, not having ability to filter based on other fields can be very frustrating and can impede your work. I know there are clever work arounds, like jamming everything into the name fields so you can search, but I really hate that approach because you are essentially duplicating information that is already perfectly captured in the system.
I think having a powerful and flexible search implementation alone is critical but it can actually lay the foundation for many other features. For example, I think this could be key to the issue of limiting relations to a subset of data when creating new entities (see this, this and this). And I assume Fibery has most of the pieces figured out since this type of filtering is already possible in views.
I know fibery team is working on a lot of important features right now, so I feel bad for asking for new things. However, I think search is actually foundational to long term success of any of these tools, but it seems to be often something that is added on after the fact and a piecemeal fashion. Most tools are looking at letting you create things with least amount of friction, but when it comes to finding them later, your mileage may vary (not saying that is the case with fibery, just general observation).