The paper has some good insights into how statecharts can obscure or confuse solutions, but some of the issues are avoided by experience or practice of using st

The paper has some good insights into how statecharts can obscure or confuse solutions, but some of the issues are avoided by experience or practice of using statecharts. Combining orthogonal states and history, for example, is rightly criticised in the paper and is the equivalent of a 'code smell' for me personally, largely because it becomes difficult to reason about the behaviour of the system being modelled. The two main benefits of state charts are the clustering notation and separation of concerns by linking statecharts with directed events (rather than using orthogonality). History is sometimes useful in specific circumstances, though those often arise from how you structured the statechart rather than a system design issue. In short I'd say to try not using deep history or orthogonality and see how you get on. Use them minimally and rarely in combination. I've found statecharts to be fantastic at clarifying my understanding of systems and their design, but like any tool, they take practice.