In summary, modeling the board game with data (state) and pure functions (state transitions) had significant benefits over the alternative OO style model in terms of the overall simplicity of the model. The OO modeling approach resulted in a model that consisted of 22 classes, 11 interfaces, 1 enum, and 271 lines of boilerplate code just to implement the classes and relationships alone, with no game logic whatsoever. On the other hand, the data-oriented approach produced an entire working implementation of the game logic in 144 lines using 31 functions (small and highly composable functions, longest of which was 7 lines).
My takeaway was that modeling in the traditional OO style can be a helpful process in getting a good feel for your problem domain at a high level, but trying to immediately translate the resulting relationship model into code is not necessarily a good idea, because the classical OO relationship model is inherently highly complected, and will bring that complexity straight into your codebase if you try to translate it word-for-word. Taking the insights from your relational model and using it as a guide to help model your problem domain as data and functions usually results in a much simpler codebase, and in turn, a much more robust and predictable application.