Confusions in git EOL configuration

Question

My files should have consistent line endings on both system following CRLF and system following LF. This github article explains how to set it up, and this git article explains more details about .gitattributes:

Checking-out and checking-in

These attributes affect how the contents stored in the repository are copied to the working tree files (...)

text

This attribute enables and controls end-of-line normalization. When a text file is normalized, its line endings are converted to LF in the repository. (...)

Set to string value "auto"

When text is set to "auto", the path is marked for automatic end-of-line conversion. If Git decides that the content is text, its line endings are converted to LF on checkin. When the file has been committed with CRLF, no conversion is done.

I understand that git will convert line endings of text files into LF as the result of the normalization when it check-in(store into the repo).

Questions

1. What does When the file has been committed with CRLF, no conversion is done mean? Does it mean that git will not convert the line endings of js files into LF if I have following .gitattributes? (or maybe it will make sure they are CRLF)

*.js text eol=crlf

2. Why does the example of the first article have following setting in .gitattributes? Wouldn't git just handle files as it used to do that doesn't match any pattern in .gitattributes?

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

3. Wouldn't above setting lead us to define additional settings like following one so git won't normalize such files that shouldn't be modified? (because * text=auto would make git treat every file as text)

# Denote all files that are truly binary and should not be modified.
*.png binary