The point here is separation of Model things that are not the model.
The Game Logic is the Model as referred to in
These are all different, related, software architecture patterns.
But in all case the Model is the same thing it's the real logic and the real state.
It is the when making business software it is sometimes called business logic, and encoded some of the businesses policies. Eg if your are coding something for a bank, to calculate credit card bills, then the functionality to cause someone to not have to pay interest if they clear their debt in less than 30 days, is part of the business logic, it lives in the model. It does not for example live on one of the displaying layers. The code for printing a bill, does not for example, edit the text based on their actions.
This example perhaps highlights why you might want to organise your code that way.
Similar goes for game logic.
Imagine that at some point your game was ported to another console.
It might help to imagine something really different to your current target.
Eg if you are targeting somehting with a gamepad/controller, Imagine your game being ported to a touchscreen tablet.
The game logic is the part of the code that does not change when you port it.
If your game were something like a military strategy game,
imagine it being converted to the worlds most complex boardgame.
The game logic is the sections of code, that directly correspond to lines in the rule book. (Not all the lines in the rule book, not the ones about moving pieces, but some.).
The game logic is the thing that never changes, no matter the form.