Helix uses tree-sitter for rich language support. Tree-sitter's grammars are binary dynamic libraries compiled from some source code. Depending on how they are written and how complex they are, they can be anywhere from few KB to many MB. There's like 150 of them ATM. It's not exactly Helix's fault that some are unreasonably large.
Tree-sitter is a large part of what makes Helix editing experience so good. Unlike regex-based parsing that (Neo)Vim uses (or at least it used to, last time I looked) which often break in weird ways and make the editor very sluggish sometimes.
Helix official releases ship with all the supported grammars pre-compiled to give a convenient fully-featured user experience. It's entirely possible to package Helix without grammars, then compile selected few and so on. Some distros and individual users do so. Grammars compiled by distros / package managers can be re-used between other programs using Tree-Sitter, so could be packages as additional (possibly optional) dependencies.
Honestly 140MB for such a good editor is totally fine with me, but people who can't live with it have plenty of routes to take, like improving Helix integration in their package manager of choice.
helix is the only editor that gets this right. shipping pre-compiled grammars should be the default for any editor leveraging tree-sitter, from a user experience perspective and for stability.
the fact that more popular editors expect you to check them out yourself and compile from master and then wire everything up yourself and "hopefully there's no incompatibility today!" is insane. we should really have higher standards than that.
More popular editors expect you to click a button when you open a file in a given language to install language support, nothing insane about that, easy and also no waste