I first learned assembler on Z80, and so the Intel syntax should be more natural to me, but I migrated from that to 68000 which uses destination-last syntax, and never really had any problems with it even though I'd been using Z80 for a few years by then. About a year after learning 68000, I started coding 8086 assembler and felt that Intel syntax was backwards, even though it's the same order as the Z80 I started on. Now it's been almost 2 decades since I wrote 68000 code, and I've drifted back to Intel syntax as the default, although I've always had a particular hatred for the square brackets for memory accesses. I remember being particularly disgusted by the DWORD PTR nonsense that the original MASM insisted on, and back in the day preferred a86 (no, not the Linux one, the old shareware DOS assembler from the late 80s) which had a much more sane syntax.
AT&T syntax also pre-dated Intel syntax by several years, and was based on the PDP-11 assembler which had the destination last. Many UNIX vendors later moved to 68000 which also had the destination last (possibly influenced by AT&T syntax, as all their 8-bit processors embedded the destination in the opcode). Other chips like SPARC, which was developed by a UNIX vendor for a UNIX-like machines followed suit, probably because all their engineers were already using AT&T syntax anyway.
As for the other arguments in the article, I think it's kind of fair to complain about the syntax, but also important to remember that as part of the GCC toolchain, the assembler was never really intended for humans to use, other than for short bits of glue code, but was instead really intended to just have enough functionality to assemble the output from cc1. When GCC was ported to Intel, it almost certainly made sense to keep AT&T syntax in gas because gcc developers were familiar with it, and the cc1 backend would probably have required extensive changes to output in a different order even though it wouldn't really benefit anyone because nobody was actually intended to read the intermediate .S file other than while debugging gcc itself. Obviously nowadays, cc1 directly outputs to .o and the -S flag is more for debug, and sometimes generates code that doesn't always exactly correspond to the generated code in the .o.
But anyway, despite all that defence for why AT&T syntax, I agree, it's ugly and I always hate writing code with it. I almost always use an assembler that uses the chip vendor's preferred syntax on whatever platform I'm using, mostly because it's then easier to refer to documentation.