Tbh, I use variants of src and opt for where things get compiled / installed respectively too. I've been treating "misc" as more of a conceptual grouping for "packages whose presence and updates are not tracked in the system by other means" rather than as an installation directory.
E.g., you may note that one of the packages the script checks for is zoom. Zoom is installed as a normal .deb file that I download from the zoom website, and install manually using dpkg, which installs it in the normal system directories. But it has its own cumbersome update check mechanism (which involves clicking a menu in the app), and is not picked up by apt-update because it's not a repo package. So this makes it a good candidate for a misc-updates check, even though it's installed as a normal .deb file. :)
I tend to make install and build scripts for such things, but one of my main things is catching the hash of the latest version, or better yet a GPG key. Gives me a little peace of mind.
I've never thought about this problem until now. Now that I see it, it makes total sense one would want to monitor those packages for changes.
What surprises me is that there seems to be no other way than hacking (cutting, grepping, etc.) each package separately. I wonder how this is handled in machines that use a lot of MISC packages (other than pulling+building every time to automatically have the latest version)?
https://github.com/tpapastylianou/misc-updater
In full honesty, I'm as proud of the "MISC" acronym as of the script itself. :p
I'm secretly hoping the acronym catches on for referring to any stuff outside the control of a system's standard package management.