Thank you, that fixed it!
Yes, timers are consistent with the FPS (from Fraps) in this case.
I actually thought SpriteBatch was supposed to take care of that... I was so wrong!
Thank you even more because you gave me enough info to make better searches about this topic, now I understand it a bit more.
Is there any documentation that mentions this kind of caveats, or they're just implied because everybody is supposed to know about them?
Yes, just using two different methods to draw each texture and calling them in the same Begin/End pair fixed it, even without Texture sorting when using the sprite atlas and repeating textures. I had tried with the two instances way because I thought the drop could be because of multiple textures with transparency rendered on top of each other, so I made the second instance to have it draw its texture at a different position, then moved it to the same position to see if that made any difference. I've kept it as example because, if anything, it should have been slower than having half of the instances, but all it was doing was accidentally sorting the drawings the right way.
It probably isn't right, I'm just doing it the way I've posted in OP, with 'texture', 'position', and 'sourceRectangle' being the only arguments passed, I just made it up quickly to test if it made any difference. For the sake of this testing it seems to work fine enough and doesn't cause any performance loss.
I just started using MG after having used a few game engines, so what I'm doing now is just testing out in a very basic way all the stuff that relies on the framework to make sure it's the right tool before porting the actual game.
Thank you both for your help!