Clarification of the Question
Most of the answers thus far make the assumption that the passage cited in the question refers to changes originating on individual developers' workstations.
To the contrary, the passage refers to change-propagation between a development server and a production server. The author should have used more appropriate terminology for the most common use-case: propagating changes from a "testing" or "staging" server to a production server. The phrasing in the cited passage is awkward, too, but the gist is that the change-propagation process should always be initiated from the production server -- that is, changes are "pulled" from the development server, not "pushed" from the development/testing/staging server.
The Rationale
The rationale is simple: in most cases, it makes a lot more sense to give a production environment access to a development (or testing/staging) server than the other way around. If the production server is compromised, the likelihood of additional harm resulting from the attacker "leapfrogging" into the development server is minimal (at least provided best-practices are observed and there is nothing "sensitive" on the development server, particularly in the way of credentials to other systems or "real" data). It goes without saying that credentials to other internal systems, real customer data, etc., should never be propagated to a development server.
A Related Aside
In cases in which a thorny problem absolutely requires access to production data, special care should be taken to "sandbox" the data in an offline, isolated system with extremely limited access. The data on such a system should be destroyed immediately after the problem is resolved. For problems that require access to other systems to be reproduced, such as a web-server that requires access to a data-warehouse instance, every effort should be made to "mock" whatever functionality the dependency provides and eliminate the need to connect the systems.
Exception to the Rule
One exception to the "rule" that the author describes is when the development server is inside the firewall and the production server is in the DMZ. In such cases, it may be that the production server cannot initiate communication with the development server (thereby making the "pull" strategy impossible), but the development server is able to initiate communication with the production server. In such topologies, in which this one-way initiation is by-design, it may be necessary to push changes from development to production.
In such cases, the credentials required to connect from development to production should be highly-guarded and should never be stored on the development server (e.g., in the form of an SSH key without a password). Further, any individual who is authorized to connect to the development server and initiate a push to production should be forced to log into his own account on both systems (accounts should never be shared among users, as doing so compromises accountability).
If root-level access on either system is required to complete the propagation, a sudo-like implementation should be employed if at all possible, as such a mechanism improves accountability tremendously.
