Digging down further into the book, the author picks this back up on page 304.
...a 1:1 representation... If I browse your live repository, I should be able to see, from a quick scan, what resources have been deployed in what environments. That is, every resource should have a 1:1 match with some line of code checked into the live repo. This sems obvious at first glance, but it's surprisingly easy to get wrong. [...] A more subtle way to get it wrong is to use Terraform workspaces to manage environments, so that the live infrastructure is there, but the code isn't. That is, if you use workspaces your live repo will have only one copy of the code, even though you may have 3 or 30 environments deployed with it. From merely looking at the code, there will be no way to know what is actually deployed, which will lead to mistakes and make maintenance complicated. Therefore, as described in "Isolation via Workspaces" on page 88, instead of using workspaces to manage environments, you want each environment defined in a seperate folder, using separate files, so that you can see exactly what environments have been deployed just by browsing the live repository.
So it seems one of the author's scruples though described as "not visible in the code or on the terminal" is more general and extends to tooling (like web svc browsers, ex., GitHub) which do not support Terraform workspaces. The author wants to know where the code deployed without pulling it down. Such that he can see what is on development and production without using a "workspace".
He later extends this to the entirety of Git branching which is slightly more bizarre, because his problem there is even smaller (pg 304),
Unfortunately, [branching] only solves part of the problem. Even though the Terraform backends provide locking for Terraform state, they cannot help you with locking at the level of the Terraform code itself. In particular if two team members are deploying the same code to the same environment but from different branches, you'll run into conflicts that locking can't prevent.
But sure, certainly "deploying the same code to the same environment but from different branches" sounds lke a real bad idea.