Apple has had to learn this lesson a few times too. It always sounds cool to an engineer to propose "let's blend search results from the local hard disk with those from the Internet" but almost all users make a clear distinction between "stuff I have locally" vs. "stuff out there on the Internet" and they don't want them mixed.
Largely because they know stuff on the Internet is potentially dangerous and full of ads and their own stuff is not, so they want the two sources (and the search mechanisms thereof) kept distinct.
Serving web search results from a generic (formerly local only) search box serves multiple strategic initiatives:
1. Gives a place to plug and train the 1P search engine (Bing) or a place to sell access to a search provider (Apple wrt Google)
2. Pretty easy but flashy feature that doesn’t require any real creativity or delivery risks but is flashy enough to get people promoted.
3. Probably user research shows that computer novices are confused by the difference between a file and web search box.
Don’t underestimate the confluence of these three things: it’s easy to justify as good for the (highly technically inexperienced) user, good for the business, and a solid path to a title bump for all involved.
It shouldn't be even cool to an engineer if you get rid of all the abstraction sauce you need to make this appear halfway elegant on a technical level.
Web search and local search don't even have the same interface: one takes a string and returns a list of web URLs based on a black box algorithm, the other takes a string along with potential other attributes and returns a list of local files that match a fulltext search.
I don't see any meaningful way to calculate a relevance score across both web results and local files.
The only reason you'd want to do this IMO is if you're desperate to get traffic to your search engine.
Yeah the one exception is OneDrive/iCloud storage, it's fine to search that, even if it only pretends to be local. But those are 'my' files, not general web search results.
