Idempotent DDL Updates

What is the general consensus within the community on idempotent DDL
scripts, ie. consistent usage of IF EXISTS/IF NOT EXISTS/OR REPLACE for SQL
init files that get checked into source control?

My experience has been that it's much easier to manage than an ever-growing
set of migration files, but I'm just a data point of one. Obviously for
other engines that don't support transactional DDL, it's a non-starter,
which leads me toward the notion that its lack of obvious popularity is due
to its limited cross-engine viability. But PG does have transaction DDL,
preventing incomplete DDL updates. However this may just be my personal
bias talking. Yet I cannot seem to discount the advantages over
ever-increasing volumes of Flyway-style migration files & directories:
* being able to do diffs of changes in source control
* limiting the size of the total SQL over time relative to what's actually
in the DB structure
* much more easily determining the most current version of a
function/procedure (this bit me hard in the past with dozens of migration
files)
* the ability to prune old changes that no longer apply to any deployed
version of the database
* treating database structure as code

The drawbacks I've run across are those areas where the EXISTS/REPLACE
constructs aren't implemented like roles management, domains, constraints,
etc. However those cases seem to be handled with only minor increases in
complexity with judicious use of inline plpgsql.

In others' opinions, has DDL idempotency been viable for maintenance of PG
databases fo you in production?

- Miles Elam