Installers are brittle. They don't always fit every case you give to them. That's why vanilla Arch lacks an installer, because chances are you're smarter than a shell script. No matter what crazy, inane setup you might be facing, Arch can tolerate it. Specifically because it doesn't have an installer.
(I once dual-booted Mac OS and Arch, with a shared /home partition. It totally worked and was a lot of fun.)
With vanilla Arch, since you're the one who brought up the system, you know exactly what you put in and why. If something breaks, you are better able to fix it. Because it's no longer magic. You did it yourself, after all. You can at least identify the parts of the system that are wrong, if not being able to outright fix them.
And since setting up the system means learning how to use the wiki and IRC channel, for most people, you already know the support network to fall back on.
Arch's installation procedure doesn't just prepare the computer for booting Arch. It also prepares you for using Arch.
If you're using Antergos et al. there's no shame in it, but you're seriously missing out on a very interesting experience.
Interesting! What caveats did you experience? Did you end up symlinking stuff like ~/.firefox to ~/Library/Application Support/Firefox?
* Linux hfs drivers don't support journaling. Solution: turn it off, and suffer the inability of Mac OS to make a disk clean without booting into Recovery or Linux first if the computer powers off in a way that would dirty the disk.
* Mac OS user/group numbering differs from that of Linux by default. Solution: modify my user/group numbers, attempt to fix permissions, apply "Fix Disk Permissions" from Disk Utility judiciously.
* HFS is not case sensitive by default. I like case sensitivity, and so does Linux. Solution: make a case-sensitive HFS volume and ignore that it leaves Unreal Engine's storefront unable to launch.
* On Mac OS, /home is no longer /home. Solution: change the advanced options of my user to change the user home folder to /Volumes/UserData/rob, ignoring that this is a pretty awful hack and that if the disk is dirty or unmounted, login will simply spin forever.
* Bash scripts (and I think node-gyp?) running under Mac OS either 1) don't expect your home folder to have spaces, or 2) don't expect it to not be at /home/username. Solution: 1) name the /home volume "UserData" and not "User Data", 2) cry.
It was an ordeal, but Arch was totally normal and never broken by it. Everything in Arch worked perfectly well. And a couple of things were not so okay in Mac OS, but never any deal-killers.
All my application settings were either just synced automatically or nicely contained in .files ignoring the Mac OS standards, so I didn't bother doing too much symlinking.
However, I didn't have the foresight to shell out some extra cash for a 256GB SSD, so I had to deal with space limitations caused by the 128GB SSD. Larger apps like XCode or GarageBand had to be either shuffled around or diligently symlinked to an external drive that would later be mounted for use of those utilities. Typically apps on Mac OS are nice enough to not spray their contents everywhere, but the Mac App Store insists on downloading things to /Applications and not where you want things (so you shuffle things around) and still some apps are not just contained in .app files but instead download things to some arcane directories. Judicial use of `ncdu` was applied to clear out some disk space, as well as just a big ol' external drive.
At least it wasn't Windows. Which would likely die horribly if you tried something like this.
I wonder if maybe I should get a blog.