The issue here is not case-insensitive filesystems, they are a huge benefit to novice users. But that the type system does not distinguish between paths and strings. A path is distinctly different from a string, and should never be compared as one. The type system should always enforce this and never allow you to mistakingly do the comparison you propose, for exactly the reasons you state. Modern filesystem libraries (for type-safe languages) do this, the problem is (as is becoming more and more common lately) the abundance of old tools that were not designed with security in mind.
As you point out, a path is different from a string. It makes sense in many cases to do a case-insensitive comparison on strings. It NEVER makes sense to do that on paths.
A path is an identifier. Just as it's infuriating and horrendous to have programming language identifiers act case-insensitively, it's a poor design choice to have path identifiers act case-insensitively.
I suspect that what you describe as a huge benefit to novice users is entirely seen in search functionality, where you are comparing a string (the search needle) against a number of paths (the haystack). Since this search should be conducted by converting the path to a string (never the other way around, that's nonsensical) it's perfectly natural to support CI operations on strings but forbid them on paths.
