It depends on how you want to design your mod system. I'll explore two of them.
Most likely you will require that your modders use the same language as you do, and load up mods via reflection (or similar, depending on your language of choice). This will obviously limit you to languages which can do late binding - and there are a good many that can do this (even C can do late binding with some clever
LoadLibrary trickery). You could even do some meta-modding, where a mod could host other mods (e.g. scripted mods).
The first problem with this approach is hiding internal state. Taking C# for example a modder could simply use reflection to access private members, C can also do this (although more effort is required).
The second problem is hosting. People don't really like foreign code running on their system with no sandbox in place. As a worst-case scenario you could write a mod that sets up a seedbox; if this was installed at an ISP it could do some serious harm to their reputation.
Modders would use a language such as Lua to create mods. You would either require a language that could invoke native code (to interface with Lua); or you would have to write your own scripting language in your language of choice.
The first problem here is that most scripting languages are interpreted, which may not be acceptable for real-time systems (although, see LuaJIT); such as games.
Ironically the second problem still exists here; taking Lua as an example I was extremely disappointed that is has 'shelling-out' functions included in the core/default library - making it entirely useless as a sandboxed environment (without a large amount of effort, luck and maintenance), it's hard to portray how angry I am about this, but I really hope they were drinking some strong cocktails when they included these anti-features. You could obviously easily avoid this if you rolled your own language (see: UnrealScript).
Finally the cost of interacting with a scripting engine may be prohibitive - again taking Lua as an example, combined with C#: C# has substantial overhead when invoking native functions (via P/Invoke) and Lua is quite a 'chatty' API. This could lead to problems if the way you design the 'script SDK' requires a lot of chatting between your primary language and your scripting language (note that C doesn't really have this problem). Again you could dodge this by writing your own scripting language (and in the case of C# compiling it to MSIL) and executing it in the quickest way under your [virtual] environment.
Because the script is essentially running on a completely different system to your primary code you can control the access to internal state entirely (unless they do some fancy stuff with the previously-mentioned shell functions).
I did veer a bit off-topic, however, what you can basically garner from that wall of text is that you should be able to make a moddable game in any language (I would venture to say that you can) - but in some languages may lead to more work. Am I a bit anal about security? Yes, you should be too when it comes to user-code.