When cryptographers talk about "security through obscurity" they're talking about cryptographic algorithms and protocols. So even systems that aim to prevent "rubber-hose" attacks could benefit by avoiding algorithms (like AES) who's security is based on obscurity, even if there are parts of the system that are obscured.
Only circumstantially in IMHO. Obscurity can be a semi-decent security tool in some situations, and in others completely and utterly useless. It depends on what you're trying to secure.
It seems like there's something like a way to measure the different mechanisms in terms of how inherently decoupled they are from their surroundings. So, a the fact you have to send messages to my server in a particular format is one type of obscurity- but it's highly non-incidental, linked to many different parts of the world (i.e. it's some common network protocol) and more easily investigated (you could get interesting different responses by vary what string of bits you send).
In comparison, which particular password I use can be very highly decoupled from the rest of the world and my architecture, which makes it vastly more (reliably) obscure.
Somewhere inbetween "you have to know my server exists to send 'login:admin password:pass' to it" and "the volume's encrypted with a 2048-bit cypher generated from atmospheric entropy" is, maybe, a useful middle ground.
Hidden volumes seem like more of a defensive meta-obscurity, in that they obscure your metadata (your ownership of a particular piece of encrypted data).
I'm aware. But Kerckhoff's principle is just saying that your mechanism of encryption shouldn't be obscured. It doesn't change that I can't define 'obscure' in a way that doesn't make it a mechanism (in itself inobscure) of obscuring data.
Also, there are plenty of historical ciphers that fall foul of Kerckhoff, I don't think we can say retrospectively that they weren't done for security, and in many cases were probably totally adequate for some time, if not their lifespan.