Reprise du message précédent :
Merci pour les suggestions. J'avais déjà testé le retour sur SDDM (j'étais déjà passé sur Plasma Login Manager, j'ai pensé que c'était lui au départ), sans aucun changement.
Pour les pilotes, vu que je suis full AMD sur mon desktop (voir ma conf), c'est pilotes libres pour la CG, mais pour tester le reste, faudrait que je réinstalle plasma, j'ai tout viré suite au passage sur Xfce4    
Sur mon portable pro (full Intel), aucun souci par contre  

Moi, j’ai ça depuis 2018 sur le PC fixe familial avec… XFCE.

Pareil : allumage et chargement de LightDM OK, mais c’est quand je veux ouvrir une session XFCE (et qu’il n’y en a pas déjà d’autres ouvertes à côté) que ça met bien 2 minutes à tout charger (pendant lesquelles la machine semble inactive, mais j’ai pu voir que c’était le processus « xfce4-desktop » qui se lançait et plantait en boucle pendant tout ce temps). À noter que ça ne se produit pas avec une deuxième ou troisième session lancée en parallèle : elles se lancent immédiatement, mais mettent elles aussi des plombes à se lancer si on a fermé toutes les autres avant. Tout au plus ai-je pu réduire le délai d’attente au minimum en désactivant l’enregistrement des coredumps (sinon, j’en aurais pour plus de 5 minutes à attendre, au lieu de deux).

C’est arrivé à peu près à l’époque où il n’était plus vraiment possible d’utiliser les pilotes Nvidia 340 sur Arch et quand j’ai basculé quelque temps sur Nouveau. Je pensais que passer sur AMD en remplaçant la GeForce 210 par une R7 240 et mettre le pilote Radeon à la place de Nouveau en janvier 2021 réglerait le souci, mais non.

Comme vous voyez, j’ai plus ou moins renoncé à chercher plus loin : ça met longtemps à se lancer, mais ça se lance quand même et aucun autre problème n’est à signaler par la suite, donc j’ai appris à vivre avec et voilà.

Cette attente ne se produit pas sur le portable (lui aussi avec un GPU AMD), où j’ai juste 5 à 10 secondes d’attente (mais là, c’est plus la faute du CPU qui a quand même 17 ans qu’autre chose).

J'avais il y a quelques mois une lenteur inhabituelle dans les boites de dialogue d'ouverture et de fermeture de fichier dans les applications Qt6, quand je fermais la boite de dialogue d'une application Qt6 ça mettait plusieurs secondes à se fermer,
 
le problème venait d'un fichier de configuration de Qt6 : QtProject.conf dans /home/*/.config, en supprimant ce fichier la lenteur a ensuite disparu,  
ce fichier faisait 128 Mo, en le supprimant Qt6 le recrée, et il fait maintenant 108 octets.
 
le problème a été documenté ici :
https://krita-artists.org/t/open-fi [...] w/138714/7
https://forum.qt.io/topic/144685/un [...] -qtproject
 
Peut-être que vos soucis viennent aussi d'un fichier de configuration lié à Qt6, qui serait corrompu, situé dans le home, ou dans /etc/, une corruption suite à un freeze du PC, un problème du SSD (vérifiez les données SMART du SSD pour anticiper d'autres problèmes de corruption de fichier et la mort prochaine du SSD),
 
Si vous avez créé un nouveau compte utilisateur pour avoir un nouveau home et que le problème avec Plasma persiste alors il faut suspecter Qt6, car Plasma repose dessus, ces bibliothèques Qt m'ont causé parfois des soucis, notamment la bibliothèque Qt6 pour la gestion du multimédia, le backend audio, si on n'a pas installé Pipewire (et qu'on a que Pulseaudio) alors la gestion du son peut merder dans les applications Qt6, et par extension les applications KDE, j'avais dû ouvrir un rapport de bug pour que les développeurs Qt6 corrigent le problème.
 
Sinon l'hypothèse d'un service systemd bogué qui ralentit le démarrage de Plasma peut tenir aussi, mais ça demande beaucoup d'investigations, de tests pour trouver la solution.
Avoir une machine virtuelle avec Arch Linux et Plasma installés peut être utile, pour essayer ensuite d'en déduire le coupable, en comparant les différences entre l'installation qui merde et la machine virtuelle où tout est Ok.