I have been reading this question and a few other answers and whilst I get the difference between changing the reference and changing the state of the current instance I'm not certain why this means that I shouldn't mark it readonly. Is this because marking something as readonly tells the compiler something special about the instance and so it is able to then treat it as thread safe when it actually might not be?
Presumably there are situations where I don't want the instance to be able to be changed, but don't mind if the state of the instance is changed (singleton maybe. /me prepares for flames) What are the consequences for marking the instance readonly if I want this?
There are no (runtime/environment-based) consequences. The compiler won't freak out, your runtime won't explode, and everything will generally be fine.
It's only FxCop (a static analysis tool that some people use) that has a warning about this. The reasons for the warning are explained in the thread you've linked to (semantically, it may not be clear that the object isn't actually "readonly", only that the variable can't be "reassigned").
Personally, I disagree with the rule, so I'd just disable it (if you're running FxCop and it is concerning you).