The boxes-and-lines is a very common way of visualizing tables and relations or types and subtypes and/or components. Also in most other so called low-code platforms. That is why it was under consideration: familiarity. I agree it is not very useful though.
Projectional editors can of course show the model as text and in other formats as well, like boxes-and-lines. You wouldn't be able to permanently place them in any specific spot then, so moving them around would at most be supported during a viewing session.
We definitely have had experience with Naked Objects before this. I can tell you the main difference between Alan and Naked Objects is the modeling language under the hood. Which in Alan's case is a specific for its use, whereas in Naked Objects, it is something like Java or C#.
Actually, in the early days we thought about whether to go text-based or not, for instance going for a boxes-and-lines type of modeling environment.
We concluded that for serious modeling, 80% or more of what one does is giving names to concepts, leading to the usage of a lot of text any way. And that boxes-and-lines introduces a lot of 'clutter' which is probably meaningful, but not in a strict enough way to do anything useful with it: x/y coordinates of boxes and lines.
That's next to there being a lot of tooling available when going text based (editors, versioning, etc), which is more of an added bonus in the short run.
In the end, we will probably evolve in the direction of using a projectional editor, making it possible to have some boxes-and-lines modeling environment as well.
Projectional editors can of course show the model as text and in other formats as well, like boxes-and-lines. You wouldn't be able to permanently place them in any specific spot then, so moving them around would at most be supported during a viewing session.