There is a reason not to, it's that the point of the class is to access the method context of the script from any class without having to pass around the context. That is explicitly what OP wanted as far as I can tell.
Utilizing methods within the main script from within the accessor is bad design, and not only because the purpose of the accessor is not to use the main script class.
You don't create separate method contexts. You use the accessor to operate on/with the context from within other classes that have their own responsibilities (single responsibility principle).
The fact that it's a singleton means nothing in regard to the api/script/whatever. The only point of a singleton is to provide a global access point to an object that is guaranteed to only have a single instance, preventing duplication of objects it contains. The example I posted is slightly weak as we're trying to ensure that the class receives a dependency through the initialize method, but if you ensure that you only ever call the initialize method from onStart, you can avoid that pitfall. Better yet, utilizing a class that inherits from AbstractScript or TaskScript and calling initialize in onStart within that class (and extending from it to create your main script class) will ensure you avoid any issues.
A well designed system does not put every piece of functionality into a single place, avoiding an anti-pattern (the blob). It's important to promote separation of concerns in your design, which the accessor facilitates.
However, I think it's a little silly to not just pass the context in the constructor as you're going to be instantiating it somewhere anyways. You could use a factory to handle the dependency injection if you really wanted.
In general, none of this is really reasonable unless you're making a large script. If OP is, then i'd design it like I would any other program. If not, sticking most everything in the script class/nodes is not that big of a deal.