dynamically generating binary packages from source packages has never been an issue for most linux distributions (despite the large number flavors and versions). that's exactly why people invented systems like bodhi/koji/launchpad to do automated packaging.
Sigh. Yes, I know the theory. But let's examine what there is now: it seems the default lazarus package distributed by Debian/unbuntu can't build itself after 15 years of package work (20+ in the case of FPC on Debian).
Which is why most people use Lazarus generated debs, downloaded from the site.
This means by the most majorly used distros (Ubuntu,Debian) this will already horribly fail due to two different lazarus builds in roulation (per distro-version).
Does it then really make sense to dream of the next step, and implement gigantic major features like binary packages?
When do you expect the distros to have it working ? By 2100?
Anyway,
yes, binary packages are worked on (though probably not in the next major version, so this is years away), but I think the main goal is plug-in architectures in your own applications.
For lazarus IDE, it is more mixed, it will of course speed up installing packages, but at the same time it will significantly delay IDE startup (most of the splash screen time of Delphi is packages initialization, and their implementation is probably faster than ours).
I wouldn't be surprised if whole swaths of more advanced users will avoid a package based IDE because of that.
It also won't make anything easier, since both contrary to delphi, there will be version mismatches due to independent building. That remains the same for source and binary. (except that with source you get a hint what is wrong with an error in a line. With binary packages you get either a message that doesn't say much ('package incompatlbe, crc doesn't match") or a fat GPF.