Sind C# Winforms ausgestorben?

Da sprichst Du aber nur für dich.

Das mag sein.

und am Ende sieht's 'ne Ecke schöner aus

Das ist Geschmackssache.

zumindest solange die Team-Mitglieder ebenfalls alle fit genug mit WPF sind

Das ist definitiv bei mir ein Problem - die Lernbereitschaft ist gering 😂

Entscheidend ist, wie viel Erfahrung man mit WPF hat und ob man sich mit der Zeit eine Art Anwendungs-Rumpf zusammengebaut hat, das liefert WPF ja leider nicht von sich aus mit.

Also ich halte mich für einen sehr versierten Entwickler, vor allem in .net. Mir ist es aber beispielsweise bis heute nicht gelungen (vielleicht auch aus Zeitgründen), in WPF eine Anwendung mit DataGrid zu entwickeln (was bei uns branchenbedingt sehr häufig vorkommt), die auch auch nur im Ansatz optisch und "haptisch" in das "Windows-Feeling" einfügt. Warum das im Standard aussehen muss wie von 1998 erschließt sich mir nicht.

Aber Fakt ist nunmal: sowohl in WPF als auch in WinForms wird seitens Microsoft nicht mehr so viel Arbeit investiert, beide sind stabil und wenn Du solide Anwendungen bauen willst, ist Forms eine gute Wahl. Wenn Du (zumindest mein Eindruck) auf optischen Schnickschnack stehst und gerne die Anwendung stylen willst, dann geht das mit WPF besser.

Wenn Du aber einfach nur eine Anwendung haben willst, die wie "Windows" aussieht, dann ist der Aufwand in WPF höher. Meiner Meinung nach.

Das stimmt, das DataGrid ist nicht wirklich gut, aber grundlegende DataGrid-Funktionen kann es und im Punkto Flexibilität bei den Spalten ist es der WinForms-Alternative Meilen voraus.
Ich hab schon einige Anwendungen damit gebaut, auch solche, die speziellere Dinge im DataGrid "nachrüsten", aber am Ende würde ich dort lieber Alternativen von Firmen (z.B. DevExpression) nutzen, denn die sind (ich kenne nur das von DevExpress) wirklich extrem mächtig und im Endergebnis sowohl für den Entwickler als auch für den Nutzer ziemlich geil.
Allerdings legt man da auch eine Stange Geld auf den Tisch.

Was die Stabilität zwischen WinForms und WPF angeht, sind beide gleichauf, beide laufen seit Jahren praktisch fehlerfrei. Der entscheidende Unterschied ist aber, dass man in WPF spezifischere Anforderungen deutlich einfacher mit Board-Mitteln umsetzen kann, wo ich in WPF schon längst im OnPain herum furwerken muss - und selber zeichnen kann je nach Anforderung sehr komplex werden, was wiederum zu Lasten der Stabilität geht.
Ich denke da z.B. an so Kleinigkeiten, wie ToolTips, in WPF kann ich ohne jedes Problem ein x-beliebiges Control als ToolTip anzeigen, bei WinForms wird das schon schwieriger.

Der Nachteil von WPF ist einfach, dass man nicht mehr ohne Weiteres einen Designer nutzen und sich alles zusammen klicken kann. Es geht schon, aber so verschenkt man viele Möglichkeiten und das Ergebnis wird schneller komplex, als in WinForms. WPF ist für MVVM gebaut und wenn man sich nicht darauf einlassen kann oder möchte, wird man damit auf lange Sicht nicht glücklich.
Diesen Nachteil könnte man ausgleichen, wenn man eine Art Rumpf (ähnlich wie Angular) hätte, aber den gibt es leider nicht direkt von Microsoft.

Den Nachteil, den ich bei WinForms sehe, ist wiederum ebenfalls der Designer. Er verbirgt die Komplexität, die man auch bei WinForms immer hat, sodass es dazu verleitet, "mal eben" etwas zusammen zu klöppeln. Heute, wenn ich zurückdenke, erinnere ich mich an kein einziges WinForms-Projekt, das kein absolutes Chaos war. Die WPF-Projekte waren auch keine Vorzeige-Beispiele, aber sie waren durch den MVVM-"Zwang" (mehr oder weniger) zumindest halbwegs übersichtlich strukturiert.
Ach ja und die stark eingeschränkte Flexibilität, die WPF mit der Trennung zwischen Control-Funktionalität und Control-Template erreicht, ich kann überall für alles ein Template definieren und die Funktionen nutzen, aber mit meiner eigenen selbst gebauten UI dazu, ohne je ein bisschen selber gezeichnet zu haben.

Abgesehen davon sind die Tools für WPF weit besser, z.B. sowas wie live UI-Bearbeiten, oder VisualTree während des Debuggens durchsuchen, gebundene Objekte, Klassen oder Controls suchen, etc. Ich hab allein heute min. zwei Stunden nur damit verbracht, irgendwelche über Umwege gebundene Objekte zu finden. Bei WPF mach ich die VisualTree-Anzeige auf, wähle mir (ähnlich der Browser-Dev-Tools) das Stück UI aus und drücke dann auf "Code anzeigen" - fertig.

WPF bietet extrem viele Detail-Funktionen, von denen viele gar nichts wissen, weil sie gar nicht auf die Idee kommen, dass es da etwas geben könnte. Sowas lernt man nur, wenn man sich darauf einlässt und die höhere Einstiegshürde in Kauf nimmt.
Und ich hab jetzt das Problem, dass ich das alles bei WinForms vermisse :D

Weil es lange nicht mehr zeitgemäß ist und durch seine "Klicki-Bunti"-Arbeitsweise fast immer zu grausigen Code führt. Zumindest habe ich noch kein WinForms-Projekt gesehen, das nicht schon längst eine stinkende Leiche war, ohne einer realistischen Chance, es zu retten.
Außerdem gibt es einen Berg von Dingen, die man WinForms eigentlich nur erreichen kann, wenn man selber zeichnet, was fast immer grausiger Code wird.

Aber meine Probleme mit WinForms hab ich hier schon ausführlicher Beschrieben.

Bei mir tauchen probleme beim UWP ein. Denn bei UWP habe ich immer das problem, das ich nicht weiß wie ich die Standart Fenster größer nach Konfigurieren kann. Und das führt beim Taschenrechner programmieren dazu, das ich immer beim Starten die Fenster größe selber Manuel festlegen muss. Und die Elemente sind beim ausführen nicht immer korrekt Positioniert was Positionieren soll. Deshalb bleibe ich bei Windows Forms, weil was mit dem Elemente und Fenster größe an geht habe ich damit keine Probleme. Daher wundere ich mich kaum warum viele Leute sich mit UWP Anwendung beim Programmieren sehr wenig Mühe geben. Ich meine schau doch mal bei Windows Store, unzällige Müllsoftware die auch Mühelos Entwickelt wurde. Bei Klassische Software sind Entwickler komischerweiße dort in der lage viel mühe zu geben und ganz viele weitere funktion zu intergrieren.

UWP ist kein WPF ;)
UWP hat noch so seine Kinderkrankheiten und ist vermutlich sowieso tot.

Aber UWP ist genau wie WPF von Natur aus responsive.
Wenn Du es richtig machst, passt sich jedes Control dem Platz an, den es hat. Das Grid ist dafür ideal, damit kannst Du nämlich Verhältnisse einstellen, die dann je Größe passen.
Viele (besonders, wenn man den Designer nutzt) arbeiten aber mit fixen Positionen und Margins/Paddins, um die Controls zu positionieren und dann klappt das natürlich nicht.

Das sieht man übrigens bei sehr Vielen, die vorher mit WinForms gearbeitet haben :P