If you want the more general advice, it is that installing the meta-package for more than one desktop environment can have pretty weird effects, and you get to clean up the mess :-P. There are some good reasons why Ubuntu and Fedora have flavours/spins i.e. different OS install disks for different desktop environments.
Of course if you find a nice clean solution, or the weird effect you find is dangerous enough, you can also report a bug and hope that Debian will solve the conflict.
The doc for
clipit --daemon (which is autostarted) says it is used "to keep your clipboard and primary contents safe." There's several things you might guess this means. However, I expect at least one of the problems it solves, is the problem that the X clipboard for copy/paste is effectively lost when you close the app you copied from. Perhaps Debian LXDE expects that you would like something to preserve the clipboard contents on LXDE.
The GNOME desktop provides this feature already. I would advise not running
clipit --daemon or equivalent in a GNOME session, in case they conflict. Maybe you found such a conflict. (Although, you don't explicitly say if you have the same problem in LXDE as well?)
(At least, I think GNOME provides a clipboard manager which works for X Windows. Some details are mentioned in this old Ubuntu document. There seems to an issue that this does not work when you use native Wayland apps and GNOME with Wayland).
The problem is that
clipit is not part of LXDE specifically. It seems plausible you might install it because you want to use it in an environment which is not LXDE, but also supports autostart. (?) This might justify
/etc/xdg/autostart/clipit.desktop or something like that, to autostart clipit in any desktop environment. Or maybe the packager felt the alternatives were awkward, i.e. creating a stub package
lxde-clipit-autostart, or putting an LXDE-specific autostart inside the non-LXDE specific
.desktop files include a line like
NotShowIn=GNOME;Unity;. Or they can use a line
OnlyShowIn=. If they don't have a specific line like that, the autostart will be started in all desktop environments which support autostart.
You could test adding
clipit.desktop. If it works, you could propose this solution for
clipit.deb, in a bug report. I don't think this is a fully general solution. A different lightweight desktop could pull in a different generic clipboard manager autostart. So it might be debatable whether this, or any other solution, could be accepted as a change to