What is your language of choice then?

Depends on the problem at hand; these days, mostly control logic in Bourne (not even bash!) shell and an AWK processing / compute core.

Do give examples of how you package everything you produce as deb/apt, rpm/yum, exe/msi/chocholatey in a way that works on multiple OS versions and distributions.

A piece of software I develop always starts out as a Solaris System V package. Always. However, the code is written such that it's completely portable to all other UNIX like systems, which makes it trivial to build an RPM. I then take alien to build DPKG's for debian, and building HP-UX's PSF's is pretty straightforward too.

I do not, and will never support Windows: first, I don't want to support something that I want to end, and second, I don't do consumer space. It's not worth it. Not having to support a braindead platform (no /usr/bin and applications in it without Windows Services for UNIX or Cygwin) like Windows makes the entire thing manageable.

I don't touch Python 3, because it's not backward compatible, therefore I boycott it, and the Python software I use requires Python 2 anyway. I don't do Java, in fact, if I catch anyone using it, that's immediate grounds for dismissal, no questions asked, not that people I work with would ever do such a thing.

PostgreSQL, Apache, and so on: we developed a generic build engine, which builds this software, so that apart from patching / porting it will compile and install the built software under a builds/postgresql-#.#-SunOS-i386[.64], for example. Then I wrote a whole bunch of tools which automate package metadata files' generation, based on command line options, like so:

% mkpkginfo -d description -n name -v ...

these then become interfaces, which a continuous integration system (or even cron, if you wanted to!) can call. Once these are finalized, they're checked into the source code repository.

There is much more to it than this that I'm not describing, like change requests, configuration management, and so on, for example, configuration packages which, when installed, automatically configure Apache, or any other application, without any human interaction whatsoever.

You seem to me to be in consumer space, writing "fat client" software for the desktop in Python, whereas I'm in the "backend" server space, developing for the infrastructure and web applications.

Life is easy for me, extremely easy, and it is so for my customers who run and administer their own machines.

Perhaps that is because they only have a handful of systems, and perhaps it is because they accept a salad of solutions, like using your proprietary packaging. I (and luckily the employers I used to work for in the past) allow no such salad. The environment is engineered to a T, and that is how we guarantee that what we deliver will JustWork(SM). Zoos and salads are strictly forbidden. It's as if you bought a laundry machine, or a Blueray player: it works, and noone thinks to mess with it, because it's an appliance. Messing with an appliance would be pointless, especially in my problem domain.

I perceive your reasoning to be dogmatic, and mine pragmatic.

And rightly so; my dogmas were shaped by years of extreme suffering in programming "zoos" and being paid to make such "salads" seamlessly work together. I'm the guy who got stuck on the brain detail of figuring out how to convert your proprietary package format into an OS package, integrate that OS package 100% with the operating system substrate, plug it into a provisioning technology like Kickstart, JumpStart(TM) or AutoYaST, and generally make it JustWork(SM). It is a gargantuan amount of work, and all because developers think exactly like you, when in fact, this was the developers' responsibility in the first place. I resent it, and view such software as incomplete. If the developers delivered their software as native OS packages conformant to System V / LSB-FHS and linked with $ORIGIN linker keyword, and if their packages contained code to fully integrate with the OS and start and stop automatically, things would be grand!