The PHP-module and its associated PHP filter may create security holes when used improperly.
The main reasoning behind the advice you've read about having it disabled on production sites, and it being removed from core in Drupal 8, is that it lowers the bar for creating PHP, making is simpler for non-programmers and unskilled programmers to add PHP to a site's code base (in particular, PHP code that don't sanitize user input).
However, the main risk is that by enabling it, some unthinking admin may give access to the PHP-filter for all users (not only the trusted user #1).
Given improper use, the site can be compromised by any script-kiddie. By leaving the PHP module completely disabled, you've eliminated that risk.
However, that being said, the PHP-module is useful in some situations (as you've discovered), and I think that it is over-cautious to never having it enabled on a production site. As long it is only allowed for user #1 (i.e. the implictly trusted super-admin), and the PHP that is added is safe (for the record, the code proposed at Create a Rule to Evaluate If a Logged-in User Has Created Content of Type X is safe), then the site is not put in jeopardy by having it enabled.
Just thread carefully, and make sure you you know enough about Drupal to understand that the PHP-filter should not be enabled for "Filtered HTML" or any other text format that untrusted users are allowed to use, and that the code you add to the HTML-textarea using this feature must by itself be safe.
PS: Some people seem to think that it is somehow "better" to add PHP to a site by writing a custom module instead of having it in the database. IMNSHO, it makes little difference where you keep it. A bad programmer is unfortunately perfectly capable of creating unsafe PHP anywhere. Having unsafe PHP inside a file instead of inside the database will not save you if the PHP-code happens to be unsafe in the first place - even if you've paid somebody to create it for you.