I’m not a Gutenberg specialist (for from it, really) but:
the wrong way is adding JS with wp-block/ wp-element and other gutenberg dependencies on init calling wp_enqueue_script,
the right way is either hooking into enqueue_block_editor_assets (see https://jasonyingling.me/enqueueing-scripts-and-styles-for-gutenberg-blocks/)
or when using init doing wp_register_script and then register_block_type referring to the correct editor_script previously registered (see https://wordpress.org/gutenberg/handbook/designers-developers/developers/tutorials/block-tutorial/writing-your-first-block-type/).
I’ve tried both of these on a “bad” plugin and can confirm both solutions do prevent those needless wp-includes/js/dist/* JS-files from being added on the front-end.
So dear plugin-developer-friends; when adding Gutenberg blocks please differentiate between editor access and visitor access, only enqueue JS/ CSS if needed to display your blocks and when registering for front-end please please frigging please don’t declare wp-blocks, wp-element, … and all of those other editor goodies as dependencies unless your 100% sure this is needed (which will almost never be the case).
The performance optimization crowd will thank you for being considerate and -more likely- will curse you if you are not!
Update 4th Feb: the HTML minify bug was fixed in W3TC v. 0.9.7.2, released a couple of days ago.
Update 19th Feb: I’m still seeing issues caused by W3TC, seems like not all is fixed fully yet.
Quick heads-up for users that have both W3 Total Cache and Autoptimize installed; the latest W3TC update (version 0.9.7.1) introduces a nasty bug in the HTML minifier which also impacts Autoptimize as that uses the same minifier class (Minify_HTML, part of Mr. Clay’s Minify). When W3TC is running the Minify_HTML class is loaded by and from W3TC, meaning AO’s autoload does not have to load the Minify_HTML from AO proper (which does not have that problem).