I've used a very similar architecture for a non-real-time game before, with great success. I had a simple action list (the queue variety) that was filled mostly with animations but also with game state commands ("wait for player to select valid move" or whatnot). I hence feel that it's an entirely reasonable architecture.
One of my particular goals was allowing the UI to play out pre-recorded games with almost no extra logic from games that were being played actively; events were fed into the view layer and it played them. This also let us easily build a local AI option to smoke test the game, which was invaluable (as it has been on every game I've worked on that had it, turn-based or real-time).
You will likely need to add more advanced scheduling to your animation queue at some point. e.g., "play these two animations now and wait for both of them to finish," or even "play these two sequences of animations, and wait for both to finish." You'll also want separate animation queues for disconnected parts of the game UI, like menus UI vs the actual game board.
The tricky part comes down to animations that are in direct response to user interaction. Say you want to have a game object moved by the player by dragging it to a desired location (in your case, say, to move a piece on the board). These kinds of animations don't fit quite as well into a queue pattern, since they are not "fire and forget" but rather are constantly updated and modified as the player interacts with the pieces. I solved this by having two different animation managers: the queue for system-driven state-change animations, and then a simpler layered animation system targeted specifically at drag-n-drop, hover effects, selection effects, etc.
Another interesting note is that you can well have a mixture of both types of animations in some cases. Say you have a long system-driven animation, like dice rolling and pieces moving in your example, but you don't want the game board to become completely non-interactive while the animations play (because that makes your game look and feel like a 1990's relic, and users expect iOS-like smoothness and interactivity these days). I solved this by having the animations in the queue control an object's "natural" transform/state, and the interaction animations controlling "actual" transform/state information (and if there are no interaction animations on an object, then the actual transform is equal to the natural one). A few specialized tweaks were needed to make it feel and look really good, but it worked quite well even without those.
While I assume you're working in 2D, I did this all in 3D, and it worked equally well there. The animations and interaction code are slightly more complex but the architecture to manage and schedule them can all be the same.