So, the crucial thing ACME has that the other protocols do not is a hole (and some example ways to fill that hole for your purpose, though others are documented in newer RFCs) for the Proof of Control.

See, SCEP assumes that Bob trusts Alice to make certificates. Alice uses the SCEP server provided by Bob, but she can make any certificate that Bob allows. If she wants to make a certificate claiming she's the US Department of Education, or Hacker News, or Tesco supermarkets, she can do that. For your private Intranet that's probably fine, Alice is head of Cyber Security, she issues certificate according to local rules, OK.

But for the public web we have rules about who we should issue certificates to, and these ultimately boil down to we want to issue certificates only to the people who actually control the name they're getting a certificate for. Historically this had once been extremely hard core (in the mid-1990s when SSL was new) but a race to the bottom ensued and it had become basically "Do you have working email for that domain?" and sometimes not even that.

So in parallel with Let's Encrypt, work happened to drag all the trusted certificate issuers to new rules called the "Ten Blessed Methods" which listed (initially ten) ways you could be sure that this subscriber is allowed a certificate for news.ycombinator.com and so if you want to do so you're allowed to issue that certificate.

Several ACME kinds of Proof of Control are actually directly reflected in the Ten Blessed Methods, and gradually the manual options have been deprecated and more stuff moves to ACME.

e.g. "3.2.2.4.19 Agreed‑Upon Change to Website ‑ ACME" is a specific method which is how your cheesiest "Let's Encrypt in a box" type software tends to work, where we prove we control www.some.example by literally just changing a page on www.some.example in a specific way when requested and that's part of the ACME specification so it can be done automatically without a human in the loop.