This "Onion" construct can be dangerous and should only be done if you have enough reviewers, it does however add multiple favorable properties compared to simple hashing:
The first unsalted MD5 can be done by clients or frontend servers. It normalizes charset and length and obfuscates passwords early on without being too CPU intensive.
The salt is read from the user database so it is not present on the client, this is was the first HMAC adds.
The crypto service (or better HSM) defends against brute force (as the secret key is not known). In fact this predates NIST recommendations to do exactly this. This peppering is not often done as it requires complicated system setup (HSM or process isolation) - something Facebook can afford.
Since the pepper step could be compromised by insiders, the data is then passed to scrypt, a function designed to make brute force testing of passwords more expensive.
The final step might not be needed, or maybe it is used to add some diversification (SHA2 instead of SHA1).
It looks a bit like snake oil overdo but the steps can be reasonable explained. If you compare it with the (much weaker) glibc-SHA2 Voodoo it is really clean.
BTW1: memorable Authenticator are generally a bad thing, such schemes can only reduce the risk of handling them.
BTW2: collision weakness of SHA1 does not apply to HMAC constructs and the short MD5 hash size does not hurt much here (as passwords almost always have even less entropy). It would be more risky for key derivation, but that’s not the task at hand.