ArchJava

The biggest advantage to using a language extension to plot out and enforce an architectural vision is that relies on tools you are already familiar with, namely, the language you're already using to create the product. This has the two main advantages of reducing the learning curve (as the extension should match the language conventions) and reducing overall complexity. During the introduction the authors mention several stand-alone tools that can be used to enforce the architecture, but every new and distinct tool you add into your code construction product gives you one more chance to slip out of date, one more chance to make stupid code errors, and one more headache when compiling or publishing your product.

As far as using this tool (or a later version) for the product found in the Memories paper I am of mixed feelings. While the description shows how it could easily encapsulate the various concerns that were talked about in the sections on refactoring in the Memories paper, it seems that it would require at least the same amount of effort, if not slightly more. So, it seems that the only real bonus to refactoring that could happen would be for future iterations where developers could clearly see the labeled connection points without necessarily referring to an external chart. You would have to balance this against the additional training necessary to work with ArchJava obviously.
Perhaps the biggest issue is that it doesn't seem like it would do much for the biggest hurdle facing the Memories product, that of making the system stable and user agnostic to reduce the workload on the people operating it. The architecture designed should help achieve this, but it would not do so on its own.
So the ArchJava extension seems only to partially assist with the needs presented in Memories, and, when it comes to adding new components, tools, or what have you, unless a clear benefit can be seen from its implementation I would hesitate in adding it to the product if only because it would be one more possible source of failure for such little gain.

I will say in its defense that ArchJava may be the sort of strict framework you would want to use for the Memory product's strict separation of Business and UI logic. Since ArchJava does to checking to make sure all communications are being channeled correctly it should be fairly simple to lock the business on one end and the display(s) on the other. This would have the benefit of enforcing the split that will come in handy preventing the repetition of code through the various view styles.