When your choices are:
1) A 16" MBP with an awful keyboard layout (death to the Command key, and put Ctrl in the corner) but a great screen and battery life
2) A Chromebook that's straightforward, reliable, but for some reason not available in a size >13" with a resolution >1080p (so a dealbreaker for development for many people)
3) A Linux laptop with all of the fun bluetooth, driver, and battery quirks that implies
Many people will choose #1. OS X is by far my least-favorite desktop OS for a wide variety of UX reasons, but when my workflow for the most part requires browser windows, terminals, and enough pixels to use many of them at once the 16" MBP is a pretty good choice (when I'm not paying, at least).
OSX lets me remap caps lock to control without digging in the registry or playing "find where they moved Xorg.conf." It's just an option in the preferences.
Emacs movement shortcuts like C-a and C-e (move-beginning-of-line and move-end-of-line) work everywhere out of the box. ^C can be kill and ^p can be previous-line because they don't collide with copy and print, so terminals Just Work instead of each having their own convention to memorize. Also, for some reason the OSX terminal is the only one that reliably gets SIGWINCH and unicode reliably correct, and has for a decade. It's weird that linux terminals are so bad at this, but whatever.
This is what good design looks like.
For native apps. Sort of.
* Though you can assign Ctrl to the Fn key, you cannot assign the Fn action to any key so you can't swap them without giving up the ability to use the Fn key at all.
* This doesn't work for web apps. Google Docs etc. will still use Command key shortcuts and will thus be different locally versus remoted into a machine.
* Some key mappings break in text boxes. I've remapped Find to Control+F, which works most of the time, but not if my cursor is in a text box, because then it moves the cursor forward. Control+B for bold and Control-A for select all are likewise. To make it worse, this only happens for certain text boxes, and heck if I can figure out the pattern.
In all, it's an incredibly frustrating experience.
Don't remap Cmd+<key> shortcuts to Ctrl+<key>. The great thing about the cmd key is that it doesn't conflict with anything else. Ctrl-f is forward, ctrl-b is back, ctrl-a is beginning of line, etc, these have been around in emacs (readline?) for a long time and it's great that native os textboxes implement them. This is why it's inconsistent; bad apps use their own snowflake controls and fail to implement them.
cmd-<key> don't conflict which is why they're used. Ctrl-c meaning both SIGINT and "copy to clipboard" is a disaster on terminals, the cmd-c life is much better. By trying to remap cmd to ctrl you're working against the OS and the OS will fight you back because it's not designed to do that.
In Linux you just have to add 'include "capslock(escape)"' in xkb symbols file and it works on any Linux distro. I just set it up in my dotfile installer in 2013 and never had to fiddle with the interface since.
I never have to wonder "where did they moved the option in the interface this time?". It's just a script I have to run when I set up a new distro install.
Most of Google's services have a corresponding iOS app which requires a Mac to build / run a simulator. So if you're not actually picky about computer then it's more practical to have a Mac as it can handle debugging for Web/Android/iOS.
If you're at a desk you can have a dock with a different keyboard.