First, a quick aside. You seem to have a slight misunderstanding as to how servos work. Servos are not controlled by PWM, and they do not know or care that you are sending pulses at 49.whatever Hz. They do not know the pulse is some percentage of some arbitrary period. The servo couldn't care less what the time between pulses is. I say this because you seem unusually focused on things that don't actually matter.
Servos don't even really know or care that the voltage is high or low at a given time. They only care about one thing: the time between a rising edge and falling edge.
The servo is controlled by detecting a rising voltage edge, and measuring the time until there is a falling edge. Valid times are usually between 1.0 to 2.0ms, but it can vary from servo to servo.
You can control it at 1Hz, 10Hz, 50Hz, 100Hz. Most will respond to even higher pulse rates, but again this is variable. What I am trying to say is that the frequency, duty cycle, duration between pulses, all could not be less relevant to your problem, which is that the servo isn't responding when you expect it to.
The only thing that is relevant is edges of your pulse, which you have not given any attention to. If you want to figure this out, please start by looking at the things that matter, give close up captures of your pulse edges, that sort of thing. You've captured nothing useful in those screen shots, which is probably why there doesn't appear to be a problem or difference. There are a lot of problems or differences that would never be visible with what you've measured.
What I can see is that the capture of the non-working pulse train is noticeably dirtier, both the pulse and the ground, than any of the others. Which is odd, as it should be calling the same function as the others. Why is that one so much noisier?
More importantly, in the nonworking capture, look at the 'fall time'. 809µs? Your oscilloscope thinks it sees a fall time lasting 0.8ms. That is...bad. Clearly that is incorrect, but the fact remains, that is what it measures.
That is a classic sign of a dirty edge. Think about it. If this pulse is fooling your high end piece of test equipment that is your oscilloscope into seeing a ridiculously long edge or fall time, or maybe so dirty it just can't correctly detect the falling edge all the time (or who knows), then what chance does that poor crappy little $8 servo have of picking up a decent falling edge?
If a servo doesn't get a valid pulse (like if the falling edge takes too long, is too dirty, or is missed) within the acceptable pulse range, and by the servos reckoning by the edges which may or may not have anything to do with what you consider the pulse edges to be, then it responds just as if it were off.
In other words, not only does it not move, but it will not resist its shaft moving. It will simply be limp, exactly as you're seeing.
Now, this begs the question.... why would calling servo.write effect the edge quality?
You said a clone. Like this one?
These clones in particular tend to behave erratically due to the incredibly poor decoupling. There should be decoupling capacitors on every power pin, and as close as possible to the mega2560. And on the actual arduino, indeed there are. On these clones however, they are much too far away, or perhaps missing, it is hard to tell. Its obvious from looking at the board that it will not behave reliably, that is the important thing.
So what is the difference though?
When you call servo.write, it pushes the stack higher than if you call writeMicroseconds. Given the mega2560's 3 byte stack pointer (17 bits), it is having to flip a bunch of critical bits that it doesn't have to when you call writemicroseconds. I know this seems like an unlikely difference, but I've experienced my fair share of poorly decoupled microcontrollers, and atmegas in particular seem to exhibit odd behavior specifically when using timers and/or pushing or popping the stack. Something similar happened for me, only the stack was corrupted when I was trying to drive LEDs with PWM, but if I put everything inline without pushing the stack, it worked. Poor decoupling was ultimately the problem.
I would fully expect poor decoupling to be able to, for reasons known to that atmega2560 and no one else, are having a detrimental effect on the edge quality of that pulse, but only when you are pushing the stack right before. This servo is just not quite able to handle the way those edges are being sullied, so it sees no valid pulses in that case. Other servos obviously manage it.
Decoupling stuff is always bizarre and hyper specific like this. Which is why decoupling is so important. Keep the nightmarish hell of problems lack of capacitance can cause you at bay with nice fat ceramic caps and as close to the chip as is physically possible.