The issue isn't GETs in general. It's limited to GETs that lead directly to a change to the database. These could theoretically be picked up and used out of context, in particular to bypass the protection added to Zen Cart to defend against Cross Site Request Forgery (CSRF) attacks.

Examples might be a delete confirm box that relied on a button wrapped in a link that passed details of the thing to be deleted as a string of GET parameters only. Normally that link would only be generated when a user hits a delete button, but a similar one could be constructed and used during a CSRF attack.

That's now prevented by checking a security token passed as a POST var against the one held in the session array. So those "destructive" GET actions have been converted into forms with the security token passed as a hidden variable (the zen_draw_form function automatically adds it). Usually the id of the thing being deleted is passed as a POST var too. Though that's not essential as long as the code forces at least one other piece of information to be present in the POST var before the database change can be executed.