In my experience:
Property Grids focus on consistent, simplified programmability, whereas a dialog caters to task-specific UX, leaving more room for "manual UX optimization".
Property grids are usually "driven"*) by a generic enumeration of available properties and their types (where type defines valid values and method of input). With such an API in place, adding or changing properties does not require UX changes - they happen automatically.
In addition, such an API simplifies property-related non-UI functionality, such as generating a report of settings, copy+paste of settings, automating data exchange, etc.
At last, such an API, in combination with a property grid, massively simplifies the integration of 3rd party components, and makes them appear "more native".
So the adoption of property grids is driven by development cost and componentization (if that's a word), not by being a better UX as such.
From that point, and with a few terrible examples in mind, I can udnerstand why someone comes up with a "no property grids" rule.
Understanding why does not imply agreement, though. A dialog is better only if it is well designed, which is in my experience a very time-consuming task.
A blanket "no property grids" rule would be the equivalent of a restaurant's "only hand-peeled potatoes": there may indeed be a market niche for that, but it's hardly a unique selling point that generates significant additional revenue to offset the cost.
*) in more than one sense: the implementation interacts with a generic API, and the availability of such an API drives the adoption of property grids because the combination reduces UX work significantly.