The second one is more work and it's what you want. Because it gets stuff into the main archive that everybody benefits from in the future. Otherwise your project is a series of hacks that create an unmaintainable mess.
I question how one gets here, nay, the 'problem' we're solving.
Presumably there's config management involved already capable of shipping bits. ie: the repo definitions to find these hackjob packages, or deliver them directly.
If this is what you're willing to invest, go Slackware at it - use a tarball. You aren't gaining anything notable by throwing an archive at a packaging format.
The meta that FPM ignores is what provides packages their value! If changelogs were at least a part of it, I'd be a bit more accepting.
Otherwise, I see it mainly as misappropriation. Best case, naive and well served. Worst case, giving the impression of better distribution than actually exists
An organization that does packages, but leaves this as the answer, fails itself and the members. Over 90% of the purpose is dutifully ignored/not standardized
Especially with DEB and RPM, where the packaging format supports arbitrary hooks that run as root, this is a big deal. High quality packages that meet distro standards will inspire confidence in customers' sysadmins. Substandard packaging may do disservice to your core software's brand, if your actual software is more solid and thoughtful than the packaging.