If we consider sigfigs, then isn't 100 and 100. two different numbers given one has a single significant digit and the other has 3? For 101 and 101. it doesn't matter because both have 3 significant digits. Then again, one may argue that it is better to write 1e2 and 1.00e2 instead of 100 and 100.. It also avoids the weirdness of the double period if the number with a dot ends a sentence.

On a personal level, I also don't like ending a number with a . because my brain immediately parses it as a sentence ender and it interrupts my reading flow.

It has nothing to do with laziness in typing.

It's just not wanting to keep track of more rules. If you've only ever used languages where a leading decimal point is allowed, it's a pain point to suddenly have to remember that it isn't here, and for no obviously intuitive reason.

It's about wanting to avoid unnecessary conceptual friction. Not lazy keyboard usage.

(Heck, your second example uses an extra keystroke. And it's perfectly readable to me, based on the languages I use.)

I never understood leading dot until I understood that native speakers indeed say ".3" (point three).

Trailing makes it a floating point type instead of an integer

It’s not about readability, it’s being realistic about other humans and making software robust in the presence of common, trivial, unambiguous “errors”.

Reference: Postel’s Law

https://www.laws-of-software.com/laws/postel/

Well what's more readable, .8675309 that is understood to have an implicit zero, or the parser giving up and unexpectedly making it a string? Maybe it's not your preference but I can't see any problem with making this more robust. The trailing one is strange to me but leaving off a leading zero isn't unusual at all for written numbers in my experience.