I think you are talking about different things. I have absolutely decompiled obfuscated third-party Java libraries, fiddled with a few variables or method signatures, and recompiled + used them.
You're correct that obfuscation of Java libraries has nothing to do with Java stack inspection/JVM security... but the latter is what the article talks about and what is cited above, so not sure why you have just now brought up decompiling obfuscated Java libraries, which is, as you say, totally unrelated...
"Java-style stack inspection can restrict user or library code to deny access at runtime to unauthorized methods.",
which doesn't seem true to me, if the user has access to the library binaries. It's very possible for the user to just patch the library and use it however they want. It's possible (although I'm not especially convinced) that you can prevent the user from reflectively doing this at runtime, but that's not the only way to access unauthorized methods.
Yes, the OP has this backwards. The Java sandbox would allow an application to limit the access granted to a library to protect from a malicious library. It does not protect a library from being used by an application in way that was not intended by the library creator. It is certainly not a means of enforcing a licensing scheme.
JVM security has nothing to do with this.