In most cases these problems would fall into the category of "undefined behavior" (not in the C++ sense, but in a more broad understanding).
What you'd be doing is essentially circumventing the abstraction provided by MonoGame (as an example, this of course applies to basically any such higher-level API). In doing so, you can cause class invariant guarantees to be violated, which in turn means the assumptions the MonoGame authors were able to write their code under may no longer be true and the code may behave unexpectedly. Your own code can really no longer rely on the abstraction's invariant guarantees, either, since you've broken them.
This unexpected behavior will include, potentially, the entire gamut of such behavior from simple rendering artifacts to crashes or memory corruption.
For example, if you fiddle with some rendering API state by end-running around MonoGame itself, it may not be able to detect that state change (because it probably won't poll the underlying API for changes, it's more efficient for it to simply assume it's the one controlling the API and track those changes itself). Consequently it may decide, on the next render pass, that it doesn't need to update something that should in fact be updated and your scene may not correctly render.
Or you could mess with the underlying API and alter the reference count of some device object (assuming D3D), which means that it may get prematurely released from under MonoGame or accidentally not released, resulting in a probable crash or resource leak.
Or you could do something that works, but because you are mucking about in an unsupported manner and with undocumented features or unexpected access patterns, you could find your code horribly broken on the next release.
Or you could do something, it works fine for a few versions, but later you run into some other bug and have difficulty tracking it down, so you ask the MonoGame folks for help, perhaps sending in a bug report because you're sure its a problem in their code. They can't reproduce the bug, of course, and it finally comes out that you're doing this weird direct-access hackery and at that point -- regardless of whether or not your hackery is the root cause of the bug -- they'll probably stop spending resources on your fix simply because you are doing an unsupported thing (or at least, they'll likely de-prioritize you).
Of course, in some cases you might absolutely have to circumvent the API, perhaps to work around a bug in shipping software for which the official patch will not be released in time. If you absolutely have to do this, you should take the soft approach: try to scope your direct access as narrowly as possible, and make sure you try to leave the state of the underlying API as unchanged as possible when you are finished with your meddling. It's not a guarantee of success, but it can help.
Ideally you'll avoid this kind of thing entirely, though.