Clearly you haven't dealt with a Mastodon instance having a major defederation event.
For most users, regardless of the validity of the defed, the user experience is terrible. Their social graph just suddenly, stops working, the people they follow can no longer see their posts, all because of the actions of a few bad actors or administration failures.
This paired with the fact that maybe only Firefish or Misskey lets you (mostly) seamlessly migrate to a new instance with your data intact, and the lack of a standard way to see what followers you will actually keep when you migrate, means that the defederation experience is sucks, and migrating to a different instance to escape that is a pain in the ass.
Meta has already shown it has piss poor moderation in the best of times, and actively boosts incendiary content in the worst of times, all while collecting, profiling, and exploiting your data. It's literally inevitable that they're going to break the rules of all but the free-est of free speech Instances, so for the privacy, safety, and headaches of everyone in the fediverse, we might as well save ourselves the trouble.**
That uses a similar approach to the wake word technology, but slightly differently applied.
I am not a computer or ML scientist but this is the gist of how it was explained to me:
Your smartphone will have a low-powered chip connect to your microphone when it is not in use/phone is idle to run a local AI model (this is how it works offline) that asks one thing: is this music or is it not music. Anyway, after that model decides it's music, it wakes up the main CPU which looks up a snippet of that audio against a database of other audio snippets that correspond to popular/likely songs, and then it displays a song match.
To answer your questions about how it's different:
the song id happens on a system level access, so it doesn't go through the normal audio permission system, and thus wouldn't trigger the microphone access notification.
because it is using a low-powered detection system rather than always having the microphone on, it can run with much less battery usage.
As I understand it, it's a lot easier to tell if audio seems like it's music than whether it's a specific intelligible word that you may or may not be looking for, which you then have to process into language that's linked to metadata, etc etc.
The initial size of the database is somewhat minor, as what is downloaded is a selection of audio patterns that the audio snippet is compared against. This database gets rotated over time, and the song id apps often also allow you to send your audio snippet to the online megadatabases (Apple's music library/Google's music library) for better protection, but overall the data transfer isn't very noticeable. Searching for arbitrary hot words cannot be nearly as optimized as assistant activations or music detection, especially if it's not built into the system.
And that's about it....for now.
All of this is built on current knowledge of researchers analysing data traffic, OS functions, ML audio detection, mobile computation capabilities, and traditional mobile assistants. It's possible that this may change radically in the near future, where arbitrary audio detection/collection somehow becomes much cheaper computationally, or generative AI makes it easy to extrapolate conversations from low quality audio snippets, or something else I don't know yet.