Looking at the components the bug is categorized under, I'm assuming this is the tracker for libvirt bugs also.

The qemu://session feature may not be useful for most users because it doesn't have decent networking support. I believe the same has been documented in the libvirt FAQs too.

And for desktops/laptops, libvirtd's socket activation was the perfect feature.

How are you planning to fix this?
I think the simplest option is to not ship the libvirtd socket in standard path. Instead ship it as plain text unit in /usr/share/doc/ and let the individual make the extra step to enable socket activation.

That and some documentation should suffice ?

Please consider re-adding the option to have libvirt socket activated. I use libvirt-daemon only occasionally (I don't have any VMs configured to start at boot, and whenever I want to use one, I'll execute virsh start ...), and it's quite annoying to have to remember to start the service. Socket-activation is a very useful feature for certain uses.

(I think that the justification for removal of libvirtd.socket was misguided: any admin who understands what socket activation is, will know that the service is not started if it disabled and only the socket is enabled, and that the service will not do any work until the socket is activated. This is not special to libvirt in any way, and people seem to understand this in general.)

If you think that users will be confused by socket activation, a check could be added when a machine is set to start at boot, if libvirt.service is enabled.
systemctl is-enabled libvirt.service, a.k.a
busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager GetUnitFileState "s" libvirtd.service

If that is not possible, I think we'd be better of with having the .socket file and just adding a comment there, rather than not having it at all.

Please find a way to give laptop users a method to enable a socket service so we don't have to manually pollute the systems with custom systemd socket files.
I have a low ram machine and every megabyte counts. Keeping libvirtd running is a waste of 
 Private  +   Shared  =  RAM used	Program
 27.4 MiB +   2.6 MiB =  29.9 MiB	libvirtd
thanks.

This was addressed a few months back with

commit ee16a195d97315ba3610b3640d347d3f4a358b55
Author: Michal Prívozník <mprivozn>
Date:   Fri Oct 4 16:57:04 2019 +0200

    driver: Introduce virDriverShouldAutostart()
    
    Some of objects we manage can be autostarted on libvirtd startup
    (e.g. domains, network, storage pools). The idea was that when
    the host is started up these objects are started too without need
    of user intervention. However, with the latest daemon split and
    switch to socket activated, short lived daemons (we put --timeout
    120 onto each daemon's command line) this doesn't do what we want
    it to. The problem is not new though, we already had the session
    daemon come and go and we circumvented this problem by
    documenting it (see v4.10.0-92-g61b4e8aaf1). But now that we meet
    the same problem at all fronts it's time to deal with it.
    
    The solution implemented in this commit is to have a file (one
    per each driver) that:
    
      1) if doesn't exist, is created and autostart is allowed for
         given driver,
    
      2) if it does exist, then autostart is suppressed for given
         driver.
    
    All the files live in a location that doesn't survive host
    reboots (/var/run/ for instance) and thus the file is
    automatically not there on fresh host boot.
    
    Signed-off-by: Michal Privoznik <mprivozn>
    Reviewed-by: Daniel P. Berrangé <berrange>