Das Hauptziel sollte sein, dass der Code möglichst gut lesbar ist und keine Überraschungen enthält.
Dementsprechend würde ich bei Feldern es wirklich mehr oder minder verbieten den Typ mit in den Namen zu schreiben.
Und auch sonst würde ich es vermeiden wollen, weil es meist keinen Mehrwert bringt. Entweder wird der Typ aus dem Kontext klar, wenn ich es lese. Oder ich arbeite damit - dann sagt mir die IDE das. Wenn ich den Code lese, der Typ zum Verständnis wichtig ist, aber er aus dem Code nicht hervorgeht, dann sollte man zuerst sich fragen, ob der Code so wie er ist, sinnvoll ist und ob man den nicht besser schreiben kann. Den Typ in den Namen reinzukodieren wäre nur die letzte Möglichkeit.
Wo ich es teilweise für sinnvoll halte, wenn ich in einer Funktion konvertierungen von/nach String mache - also das gleiche fachliche Attribut einmal in seinem "nativen" Typ (z.B. LocalDate) habe und einmal in seiner String-Darstellung. Da finde ich es ok, wenn ich neben "beginnDatum" dann eine lokale Variable "beginnDatumString" habe um die klar bei lesen voneinander zu trennen. Das wäre für mich eine der wenigen Ausnahmen.