The real problem I see is a system composed of over 3500 frequently changing modules, all with the concept of repeatability (ie release versions) removed. The issues with snapshots only aside, the core issue is the massive number of modules involved.
I mean what is the ratio of modules to engineers? I don't know the size of their engineering team but assuming it's around 100, that ends up with 35 modules per engineer!
Looking at it from another perspective, what's the ratio of modules to features in HubSpot and their internal tools. My guess is HubSpot has less than 3500 features...so now you have more modules than features?! That implies that functionality for a single feature spans multiple modules and isn't organized properly. Again, a fundamental architecture problem that should be solved rather than patching maven to work around it.
Even with a magic build tool to handle this at build time, the system is so complex just with modules alone that it's fundamentally unmanageable in any holistic way, which is probably why they stopped bothering with releases and went to a snapshot only approach.
My unsolicited suggestion to them would be to focus on reducing the complexity of the modules and their interdependencies along quantitative metrics like modules:engineers or modules:features ratios. It varies by org of course but in general, worst case should be no more than one module per engineer and definitely less than one or equal to one module per feature.
It's great that they've open sourced the tool but if they don't solve the underlying complexity problem of their system they're going to spend most of their time solving problems that they've created. This time would be better spent moving their product forward which would benefit all stakeholders at HubSpot.