Is the above a correct summary?

Yep :)

The results were 'shocking' most example DDS files are already in sRGB, which would mess up gamma correctness with this approach.

Unless... input sRGB DDS textures are not converted to sRGB because they already are.
Not 100% sure how DDSTextureLoader does that, I'll have to do some testing to see the differences.

With files on disk, you never want to ever convert between 8bit sRGB and 8bit linear RGB. sRGB acts like a compression scheme, allowing RGB images to be stored with less bits. Without sRGB/gamma, we'd have to use 10-16bit linear images to get the same quality (or just full float32). If you ever have data in one of those formats and you convert it into the other, you're performing a lossy operation.

The forceSRGB option doesn't edit the pixel data at all, it just changes the DXGI format. The only difference between the DXGI_*_SRGB and the DXGI_* formats is that the former tells the shader to do automatic sRGB<->linear conversions when reading/writing.

If you have colour data that's been authored by an artist on a typical monitor, then having it use a DXGI_*_SRGB is what you want. If the DDS file doesn't do that, you can use the forceSRGB option to 'fix' the format choice on load. On the other hand, if a texture contains data (not colours) such as a normal map, then its DDS certainly should not be using an SRGB format.

My expectation was that alle 3 would give the same result, but that's only the case for A and B. C gives a visually different DDS with BC1_UNORM format, no SRGB (the texture is 'lighter' in it's colors). Any idea why this is?

One of these options might actually be editing the pixel data, performing a linear->sRGB conversion on the colours, rather than just setting a bit that says "this data is sRGB".

As above, you really don't want to do that. You just want to tell D3D that your "colour textures" are sRGB, and that your "data textures" are not.