> Using the same logic I can't assume that the reference is to `int` and not to `std::string` as you can mess up dynamic types too.
> Or reference point to some uninitialized memory.

What? Where did you get that conclusion?
We can and we do assume that the reference to an int references an int, even tough that is not always true.

> If you have null ref then it means your code is broken elsewhere, if you have null ptr then you need to consider if it should be or not be null here in the first place.

Yes! That's what everybody does. That's the implicit contract that is taken when using references.
It's not that it can't be null. It is that when I write code I'm going to assume that it isn't invalid, and if there's something the check the user of the interface has done that check.

That's why the argument of using (.) to dereference a pointer is bad, it has negative value.

If "var" is a reference and then changed to a pointer, code like:
var.member
should fail to compile, and that is a good thing, because you changed the contract.
Because you have to re-write it as
var->member
you have to opt-in, "this code assumed that references can't be null, but now it uses a pointer which can easily be null, I have looked at this code and accepted that I have done the necessary checks to dereference it".
Had "." been allowed to dereference a pointer, this would have gone unnoticed.

That was the argument, this syntactical change not only doesn't have a positive value to change, it has a negative value if you do.