is of 18 digit ID really case insensitive?

The parity bits are meant to help systems that ignore case sensitivity to properly find records where the short Ids differ only by case. For example, SOSL can't tell between case, so if you're logging Ids into a text field, the long Id will correctly find just the records you want.

It does not mean you can, or should, freely modify an Id's case. It simply means that systems that can't tell between lowercase and uppercase, usually as a convenience to users, won't match up records incorrectly.

In general, you should always prefer to use the long Id when possible, as it increases interoperability with various systems.

---

As an example, consider these two ID values:

0019000001AWn2oAAD
0019000001awn2oAAA

If you were to use just the 15-character form, they then look like this:

0019000001AWn2o
0019000001awn2o

If you try to compare them in Excel, you get an "unexpected" result:

="0019000001AWn2o"="0019000001awn2o"  (TRUE)

This makes normal VLOOKUP functions fail, because Excel doesn't normally care about case sensitivity.

However, using the long version:

="0019000001AWn2oAAD"="0019000001awn2oAAA"  (FALSE)

Solves the case insensitivity issue. This allows the external system to properly match up records when it considers uppercase and lowercase to be an equal value.

The 18-digit Id is only case-insensitive in regards to uniqueness. It will not work for queries/urls/etc. without proper casing.

You're not the first one to experience this issue. As far as I can tell, @DanielBallinger was the first to explain how to fix the casing of an Id here (via C#) and there are a couple ports to Apex here.