I finally found some time to look into this.
- Hyperkitty doesn't need (or use) less.js/lessc at all. It can safely be removed from COMPRESS_PRECOMPILERS.
I've now done this in the Debian mailman3-web package and hope to get this into Buster before release.
- The situation is different with sassc, it's actually used for compressing CSS by hyperkitty. Doing the compression at build-time should be possible but requires more work. I have a plan ;)
For that, I now also have a working implementation as well. Due to the change being rather invasive, I will not push this into Buster though. And my plan slightly changed during implementing it, see below ;)
I was wondering if we could by default not install node-less/ruby-sass and what exactly that would imply.
@Jonas M.: what do you think about  (again maybe after Buster)? Sorry to not know more of this yet, but I hope suggesting what I think might work helps to get us the right way.
I'm absolutely in favour of getting rid of the sassc runtime dependency. After a chat with Jonas Smedegaard (thanks for his valuable input!), I think that I have an idea and a roadmap on how to get there:
static/hyperkittysass/hyperkitty.scsswith sassc at build- time and patch
templates/hyperkitty/base.htmlto reference the resulting CSS file.
That's what I did now, and it already was enough to drop the build-time dependency on sassc. Django-compressor is still used to combine several CSS and JS files into one by running 'django-admin compress' in the postinst script of mailman3-web, but since the source files are already clean CSS and JS, no external processors (like sassc or lessc) are required.
I think this is perfectly fine and I don't see much benefit in combining the CSS and JS files at build-time. It would allow to drop the django-compressor dependency but with the cost of more heavy build-time adjustments that need to be maintained in future.
So I'm happy to now have a solution to drop both node-less and sassc from runtime dependencies in the Debian package. Thanks to everyone for their input on this topic.
I added a comment to upstream hyperkitty issue #120 where I proposed to do the same in the upstream hyperkitty release process and that way get rid of the sassc runtime dependency: