3. How do we decide from which viewpoint(s) to manipulate the model, and when?

It's all well and good having a rich, insightful set of ways of thinking about a system's design - whether from the PoV of the requirements it will support or the technical underpinnings needed to make it run.

But when I start, by box is empty.  There is no "system model".  Where to start?

It depends!  There are many starting points, depending on the nature of the challenge we face:

1. Maybe we need to enhance an existing system, in which case we may need to "reverse engineer" our model, based on what we observe in the real world... in which case the favourite entry point might be "physical/technical/operational":  this is the most concrete viewpoint, with hardly any "design information" left out, fully documenting the system's structure in terms of real hardware and software.  This allows us document "everything" in a structured way; before we begin to analyse what we've discovered and documented, thereby creating the more abstract (but usually more interesting) views that help us understand how the system works, and eventually what it actually does in business terms.
2. Or maybe it's a brand new set of business requirements, currently vaguely understood and constantly changing, that's going to be deployed as a new application into an existing IT environment.  In which case we may need to start in TWO places - not only the "logical/requirements/functional" views to tease out exactly what's what, but also the reverse engineering views that will help us understand "the art of the possible".

But, and here's the power of the box at it's most obvious - as these starting-point's views emerge, IMHO it's vital to check what things look like through the other viewpoints... for example in #2 above "if this were to be a requirement, what's the implication on the existing infrastructure?  Let's look at the "logical/technical/operational" views!".  And all this then has an obvious consequence - not only might it be necessary to change the model seen through the original requirements viewpoint, it's almost certainly going to be necessary to change the model through the other viewpoints too... and at the same time!

In other words, the box allows you to step away from the tyranny(!) of process, in which we've historically been made to follow a rigid sequence of activities "to design the system".  Instead, like a real engineer, we can use our own common sense and understanding of the goal (a viable system design) to create a holistic end-to-end model, through whatever viewpoint we need, in order to form the basis of future detailed design, development, deployment, delivery and decommissioning.

FOOTNOTE:  It is beyond this blog to discuss the well understood mechanisms and transformations available to the solution designer as they traverse the box's views from boxlette to boxlette.  Suffice it to say that these techniques are, in principle, no different from those deployed by other engineering disciplines, whether it be the technique for drawing the 3rd view in BS308, or for optimising the path lengths between devices on a circuit board.