Ich versuche es nochmal mit ein paar Argumenten und Kompromissvorschlägen…
Niemand schaut das Zeile für Zeile an und das ist auch gar nicht notwendig. clang-format sollte ausgereift genug sein um nur in seltenen Ausnahmefällen Fehler einzubauen. Wenn dich das so sehr beunruhigt, dann hat @laszloh oben schon mal einen möglichen Kompromissvorschlag gemacht, bei dem in der CI für einen PR jeweils nur der geänderte Code von clang-format geprüft wird.
Damit würde sich die Umformatierung auf viele kleine Schritte verlagern wobei das unschöne daran vor allem wäre, dass es unterschiedlich formatierten Bereiche im Code gibt und der Aufwand in Summe größer ist, als wenn alles auf einmal umformatiert würde.
Nochmal: Die letzte Umformatierung war eben nur die halbe Miete. Es wird keine „ständigen“ Umformatierungen mehr geben, wenn man einmal den Style definiert, umsetzt und maschinell prüft. Momentan ist er undefiniert und nicht prüfbar.
Wie oben schon gesagt ist der Output von clang-format offenbar für Tab-Size: 4 ausgelegt. Damit sieht es besser aus wie auf deinen Screenshots.
Für dich scheint es wichtig zu sein, dass die Ausrichtung der Kommentare bündig ist. Das kann ich grundsätzlich nachvollziehen. Das führt aber automatisch auch dazu dass die Zeilen ewig lang werden und lange Zeilen (> 100 Zeichen) gelten allgemein als schlecht lesbar und sind zu vermeiden.
Vielleicht ist das grundlegende Problem ja nicht die Formatierung durch clang-format, sondern das Layout an sich. Zum Dokumentieren der Makros wäre es m. E. viel schöner wenn man den gängigen, Doxygen-kompatiblen Stil wählt:
/**
* @brief Used as dummy for RC522
*/
#define RST_PIN 99
/**
* @brief GPIO for chip select (RFID)
*/
#define RFID_CS 21
/**
* @brief GPIO for master out slave in (RFID)
*/
#define RFID_MOSI 23
Mich stört hier die Floskel „Kein Kompromiss“. Ich weiß, dass das nicht deine Grundhaltung ist, weil du in der Vergangenheit immer wieder Kompromisse eingegangen bist. Wenn es aber bei diesem Thema „dein letztes Wort ist“ finde ich das etwas kurzsichtig. Die Formatierung soll doch denen dienen, die mit dem Code arbeiten und das bist mittlerweile ja nicht mehr du alleine.
Akzeptiert, aber vielleicht findet sich ja doch noch ein Kompromiss oder eine Möglichkeit dich zu überzeugen. 
Das ist genau das Problem. Du hast Ansprüche an die Formatierung, die aber niemand genau kennt (da nicht dokumentiert) und die teilweise von gängigen Standards abweichen. Zudem sind diese Anforderungen nicht maschinell prüfbar, was bei Änderungen aus der Community sowohl beim Autor als auch beim Maintainer zu unnötigem Mehraufwand führt (auch wenn du der Meinung bist, das das nicht nennenswert ist).
Ich denke das hatten wir an anderer Stelle schon. Der wesentliche Grund warum man Code für den Preprocessor und für den Compiler nicht gleich einrückt ist, dass beide nichts miteinander zu tun haben. Details und ein passendes Beispiel siehe: vim - Indentation of preprocessor statements in C - Stack Overflow.
. ESPuino-Anfragen gibt es aktuell sehr wenig - das kommt mir gelegen. Demletzt, das möchte ich an dieser Stelle jedoch mal erwähnen, war sogar mal eine Anfrage aus Saudi-Arabien dabei (!).
. Das macht auch direkt weniger Spaß am Code in diesem Projekt zu arbeiten.
