While alternative programs exist to do almost everything I prefer something that works well, works quickly, and provides instant visual feedback. CCP4 and Phenix are stuck in a batch processing paradigm that I don't find useful for these manipulations.
Speaking as a developer, it's probably much easier and faster for us to write software that *does* do what you want, instead of piling on hacks to keep the PDB format alive another 30+ years.
While PDB is limited and has a lot of redundant information it's for the latter reason it's a rather useful format for quickly making changes in a text editor. It's certainly far faster than using any GUI, and it's also faster than the command line in many instances - and I have my own command line programs for hacking PDB files (and ultimately whatever formats come next)
Most complaints of this sort seem to be based on an unrealistic
expectation that your own experiences and skills are representative of
the rest of the community. The vast majority of crystallographers don't
have their own command-line programs, aren't familiar with the
intricacies of PDB format, and as often as not botch the job when they
attempt to edit their PDB files by hand. (I get a lot of bug reports
like this.) They're not going to care whether they can use 'awk' on their structures.
Using mmCIF as an archive format makes sense, but I doubt it's going to make building structures any easier except for particularly large structures where some extended-PDB format might work just as well or better.
There
is a lot of information that can't easily be stored simply by making
the ATOM records wider. Right now some of this gets crammed into the
REMARK section, but usually in an unstructured and/or poorly documented
format. This isn't just problematic for archival - it limits what
information can be transferred between programs. mmCIF has none of
these limitations. I have some reservations about the current specification (for instance, the fact that the original R-free flags are not stored separately in deposited structure factor files, and are instead mixed into the "status" flag, which can have multiple other meanings), but at least there is a clear process for extending this in a way that does not (or should not, anyway) break existing parsers.
-Nat