I think AntP is suggesting that the tile's position on the game board is part of the model, but the sliding/dropping animation might just be considered part of the graphical representation of the underlying game state - a transitioning animation between two game states.
Precisely this. What matters to the gamestate are the board coordinates of each tile; the model should not be concerned with how the state - or changes in state - are represented, so the physical screen coordinates are the responsibility of the view (the view being a logical abstraction of the actual rendered information). In theory, I should be able to plug in a completely different view without the gamestate model knowing any different.
It seems that it might not be possible (or - at least - conceptually straightforward) to separate these concerns completely in this case. Your first suggestion is something I was beginning to conclude myself, in that this not being a strictly turn-based game might mean that it is insufficient to store simple grid coordinates for each tile. For example, move 2 can be initiated while move 1 is still "in progress." Supposing move 1 causes a large "cascade" of tiles dropping, scoring, breaking, dropping... for multiple iterations, a second move initiated by the player long before move 1 is complete might actually affect the outcome of move 1 if some tile that would be destroyed later in move 1's tile cascade is prematurely removed by an earlier iteration of move 2's cascade.
With this in mind, controlling the transition speed in the view would mean that a theoretically read-only representation of the gamestate could actually directly influence the way a set of moves plays out. This suggests that a coordinate-based gamestate model is insufficiently dynamic and that I do - in fact - need to make real-time positioning a part of my model. It seems that my current domain model is limited to a turn-based incarnation of what I want, where moves are completed one at a time and I could simply prevent the view from accepting further input until it has finished animating the previous move.
Thanks - this has provided real food for thought!