AIX configuration was opaque with a windows registry style setup.
All the standard utilities like sed, awk, etc., were versions from 1970. It was incredibly frustrating to use. They did supply some gnu software (IBM called it "linux" software), but it was managed through a second, separate, package manager, bare rpm.
Decade(s) after every other nix had snapshots, the way to get a consistent backup on AIX was to break your boot disk mirror and backup the orphaned disk (while praying you didn't have a disk failure).
Everything was spawned directly out of inittab. No sys-v/rc/etc. scripts.
A hard down could break the journal on their filesystem rather than having the filesystem journal save your data. An fsck would not fix the journal.
Most free software did not "just build and run" on AIX. Just about anything using autoconf required a custom wrapper around AIX's malloc to prevent it from segfaulting when being run, or fixing autoconf scripts to not mis-detect missing capabilities in AIX.
AIX was not a first tier system for many vendors. I had to spend time in a debugger providing info to our SAN vendor on issues with their agent for AIX (we never had issues with their software for Solaris, Linux, or Windows).
The hardware was funky. They did "neat" things like sharing a single CDROM drive between an entire rack of servers. But, to re-assign the CD drive, the IDE bus had to be re-assigned, as well as the PCI bus. And, invariably something would be blocking this, so "neat" in practice became a PITA.
On the positives, AIX was stable once everything was dialed in, just like any other NIX. It was also trivial to create a bootable DR restore ISO for a system. And, their debugger was pleasant to use when diagnosing core dumps.
"It used to be said that AIX looks like one space alien discovered Unix, and described it to another different space alien who then implemented AIX. But their universal translators were broken and they'd had to gesture a lot." -- Paul Tomblin