So your approach is similar to this one? Doesn't this version make it difficult to add and remove components at runtime? If your entire system is based on these archetypes, I can't imagine it being particularly tolerant of adding and removing data. That's a pretty big advantage to lose. And if entities share common functionality but are in different archetype groups, you would need to iterate on each group separately, which seems a little bit silly. Also, if multiple systems were to require access to the transform component, you would need to reference it by pointer anyway so that your data is accessed correctly, which is what I would have to do in my version anyway.
The relational database like system I have here handles these cases a bit more elegantly as far as I can see. If I need to add or remove functionality, I can add or remove components by just accessing a single table without having to shuffle around anything else. Yes I may have additional lookups to do, but entities with a component signature that match a system's needs will be operated on without hassle. Although I am not primarily concerned with multi-core performance at the moment, I can also easily divvy entities up for processing.
That's just my take. I am more than willing to have my perspective changed, though.