There's no difference for standard file access. Paths like ./foo are valid because . as a path component is valid, and there is no need to deliberately make them invalid, thus they remain valid even if you're not required to use the ./ variant.
There is a difference for cd specifically: paths like foo and foo/bar aren't guaranteed to refer to the current directory when cd'ing to them – the shell will additionally try to resolve them using $CDPATH, whereas paths that are explicitly anchored using ./ will not do that. This is quite similar to $PATH lookup for executables.
Other programs may also have different treatment for bare filenames (often similarly performing a path search for names that don't contain a /). As a different example, "systemd-tmpfiles foo.conf" will look for foo.conf in the standard system directories – not in the current directory.
The ability to use ./ ends up being useful in other ways. In particular, because such a path starts with ., that means it doesn't start with - or @ or other possibly special characters; e.g. you can rm a path like ./--help.
(It is also useful for writing generic code that concatenates paths, e.g. $dir/foo still works as intended if you set $dir to ., without the need to have a special case for the current directory.)