As long as your distro doesn't replace glibc for e.g. musl or bionic, and has all the usual GNU (and X11, and DBus if you need that) userland, i.e. no odd stuff - there is no much difference. Most of the time things just work. Normally, the only time you'll have to "write software for some specific distribution" is when the distribution is unusual in its ways, but you still want to target it.
That is, unless you need to target some specific library version that's higher or lower than the usually available, incompatible with the usual version, and you don't want to have a statically-linked release variant. E.g. something that would work only with Qt5.2 but not with Qt5.6. Don't see why not to just throw it all in a tarball and call it a release. Saw this done many times, I just unpacked it, ran it - and it worked.
And that is if that's you who package your software. Usually, some user just takes it further and becomes a maintainer (or a co-maintainer, or just a volunteer who submits patches).
In this hypothetical (I hope) example, you've just subjected your users to unpatched vulnerabilities like this one: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0190
You get the normal trade-offs for this approach -- large downloads, disk space, slow security updates, UI inconsistencies but XKCD 927 doesn't really apply.
The kind of software I write doesn't exist in a vacuum where all it needs is to run AMD64 code, Linux syscalls and a canvas to draw on. It needs to interact with the system, figure out what drives you have inserted, play nice with keychains and whatever..
You can't flatpak that.
And here is this guy wanting to build number 16. There is an xkcd on this. This train has left the station.