This is an interesting case. Both yes and no.
No:
The legacy wikibits module is loaded in the top queue, which is "blocking state". Meaning other modules won't load until this is loaded (much like "jquery" and "mediawiki" base modules). This is done for legacy reasons so that old scripts using these deprecated functions will continue to work without having to add such a dependency.
Yes:
If you are using this from a newly-written script that isn't old/legacy, and this module is also loaded in the top "blocking" queue (as of writing, gadgets can't put themselves in this queue, this "Yes" answer only applies to MediaWiki core and extensions), then this dependency is required. However that should be a very rare case, since you shouldn't be using legacy code in new code in the first place. When writing new code, for importScript the replacement is essentially modules/gadgets. If you really must load a script raw and singular from a wiki page inline, then use mw.loader.load with the full action=raw url. That also improves portability by not depending on which wiki the code is ran.
So legacy gadgets that aren't migrated don't have to be "fixed" by adding such dependency on "legacy". But if you see a legacy gadget and willing to spend time on them, consider porting them for real so that they don't use any legacy code in the first place (i.e. merge them in a single script page, or keep them separate and use the 'pipe-separated' list syntax listing all page names on MediaWiki:Gadgets-definition so that all required scripts are loaded in the module (instead of lazy-loading unminified and asynchronously from inline code).
