Agreed 1000%. I have been meaning to make a similar feature request myself for a while now, but focusing specifically on the Reference (Rich Text linking) Search. With one of Fibery’s goals being to centralize things, even “average” users/workspaces can end up with 10s of databases (e.g. you sync Google Calendar, it adds four databases all by itself!), many of them with extremely similar data meant to relate to each other (again the aforementioned Gcal sync is a great example, but far from the only one). This creates total havoc when Referencing (linking) in free text as well as Search and is a daily drag on my workflow, both personal and business.
Personally I would like to simply see a more powerful Search that includes better built-in Filtering and configurable Defaults, and I had seen that as separate from the filtering/limiting for Link Search (Reference). However I can see how the two could potentially be combined without a lot of downside, at least at first glance.
I also want to note that, while I think it probably depends on how a given person or team use linking, relations, etc. for me the recent implementation of Relation filters was pretty much useless compared to the value this specific kind of filtering would have, namely for References in free text. For Relations there already was at least filtering by DB, and while the added rules are great to make it quicker and easier to find something within that type of Entity, if you set aside frequency of use and just consider how problematic linking is in Relations vs. References in a complex Workspace, the latter case is far, far more of an issue.
I would also venture to guess that having some default filtering could (potentially) make the link searching for in-line references faster. In other words if you have 50 databases (not an unreasonable number for many workspaces), searching for a given text across all 50 vs. just say 3-5 of them ought to be faster, at least in principle. That may not be how it actually works out in the implementation of course, but it could be a bonus.
Anyway, you’ve got my vote. 
Answering for myself (and possibly billyjackson as well, based on his write-up), I think what would be ideal is a per-database filter, not a per-workspace one. Maybe an ability to set a global default but be able to override per-database. So for example if you’re in the Features database, you probably almost never need to link to a Calendar Event, or a Hiring Candidate, etc. Yet if I’m trying to Reference e.g. a person that gave feedback that is in our CRM while writing something about a Feature, I might start with that person’s name e.g. “John”, but oh dear there are 10 Johns who also applied for a job opening, as well as 20 meetings with my teammate John that are synced from recurring events over the last year, etc, etc. Both totally irrelevant to References in Features 90+% of the time. Being able to filter those out and just focus on the ~5 databases I most commonly link to (Reference) from the Features database entities is what I’m looking for and, I think, what billyjackson is (at least partly) wanting as well. And it needs to be per-database, because if I’m then in the Hiring Candidate DB, editing one of those entities, I probably don’t want to link/reference to a person who gave feedback that is in the CRM, possibly ever. 
The Reference filtering needs will likely vary greatly depending on the DB/Entity.