While I understand your answer, and yes it will work, this solution seems a bit overkill just to disable one of the many framework scripts. It’s also problematic in terms of future theme/framework updates to have the user clone and overridde the entire
themeblvd.js file, just to remove one small function. There’s a lot of other JS code going on in there that a user could accidentally break, and it’s likely to be difficult, when an update comes out, to accurately identify all the new changes and map them to the child theme’s overriding
My suggestions about using filters – particularly with the global config “supports” – wasn’t only to target the enqueueing, but also (in a future release) for you to include some conditional logic to check those global configs and to only enqueue and call the functions if the configs are set to true (which they could be by default). This would allow upgrade-proof customization.