A better example would be where changing the case actually affects the semantics of the filenames involved: for example, you might have files named "formE" and "ForMe" which you're unpacking from a UNIX repository where the original authors never had to worry about this causing some sort of naming conflict. It's really unfortunate when simply unpacking such a repository to your disk ends up having one of those files overwrite the other.

(My preference is to leave the root partition case-insensitive, since some apps require that, but to keep all my data and source code on a case-sensitive partition.)

I ran into so possible reason recently. Because Linux is case sensitive. So if you're making server software locally you can easily run into a bug where you reference "SomeFile" in your build/package/website locally but on disk it's named "Somefile". Everything works. Then you push to your server and things break.

I'm not going to switch my laptop to be case sensitive but I did just run into that issue.

The issue is that programs will behave unexpectedly unless they know and respect the filesystem's rules for case insensitivity (which might be tricky when you go beyond ASCII):

    $ touch Open
    $ ls open*
    ls: open*: No such file or directory
    $ ls open
    open

What's the advantage in not being able to have a file called 'Open' in the same directory as one called 'open'?

I have had zip files fail to extract because of a file and a directory with the same name but different casing... Perhaps the question is: why wouldn't you want it?

I encountered a bug once with an open source package where it contained both a file called Makefile and makefile. Is this a good practice? No. Would it be easy to miss, because make will by default open makefile first and only fall back to Makefile if makefile doesn't exist? Yes.

Edit: Makefile existed in the tarball after makefile, so it would overwrite the real makefile with whatever junk was in Makefile, and it would fail to build.