ACME's secret sauce is the name validation challenges, not present in SCEP and other prior standards. The same people, roughly, worked on two things, one of which is made very visible in ACME a published standard, but just as important is the other side of the coin.
The Baseline Requirements https://cabforum.org/baseline-requirements-documents/ from the CA/Browser Forum set out shared rules for how a publicly trusted CA must do its job. From the outset the BRs have been clear that a CA needs to somehow validate that it's issuing the certificate for some-fqdn.example.com to the people who actually have some-fqdn.example.com or else this PKI is futile. But until relatively recently the BRs were pretty vague on how exactly they ought to do that. As a consequence some CAs did an admirable job, many did a passable job, some were a bad joke either through not grasping the threat model or just ordinary incompetence.
A trusted CA for example once had a system which would check you owned www.example.com by connecting to example.com over HTTP and making a request for a magic document, say http://example.com/xyzzy.html then it would grep the reply from the server for a magic string, which was the same as the name of the document, in this case xyzzy, and if it was found the check passes. But wait a minute, this means if your server says "404 Not Found: xyzzy.html was not found" the check passes and you get a certificate. Oops. Now, not checking for a 200 OK was a bug, but even if you do check for 200 OK this validation clearly more of a polite "Keep out" notice to bad guys rather than any sort of actual defence.
So in the same period Let's Encrypt was being set up and ACME was being defined, the CA/B Forum also reformed the BR definition of how to validate DNS names using some of the same personnel. The result is the Ten Blessed Methods (although right now there are actually more than ten of them) and ACME is an automation of just three of those specific methods. Since then CA/B Forum has also worked on obsoleting the riskier and less useful methods and creating newer safer ones. Today that would be /.well-known/pki-validation/xyzzy.html safely in a reserved namespace, and it'd need a value inside it that's either entirely random or is determined by some other factor not under an attacker's control (in Let's Encrypt the equivalent string is a hash of the LE user's public account key).
Some of the Ten Blessed Methods are inherently kinda manual. Some just aren't very universal. So ACME and Let's Encrypt focus on the three which are most suitable for automation, surfaced in a way that is hopefully even more secure than required by the BRs and made available to everyone.
The Baseline Requirements https://cabforum.org/baseline-requirements-documents/ from the CA/Browser Forum set out shared rules for how a publicly trusted CA must do its job. From the outset the BRs have been clear that a CA needs to somehow validate that it's issuing the certificate for some-fqdn.example.com to the people who actually have some-fqdn.example.com or else this PKI is futile. But until relatively recently the BRs were pretty vague on how exactly they ought to do that. As a consequence some CAs did an admirable job, many did a passable job, some were a bad joke either through not grasping the threat model or just ordinary incompetence.
A trusted CA for example once had a system which would check you owned www.example.com by connecting to example.com over HTTP and making a request for a magic document, say http://example.com/xyzzy.html then it would grep the reply from the server for a magic string, which was the same as the name of the document, in this case xyzzy, and if it was found the check passes. But wait a minute, this means if your server says "404 Not Found: xyzzy.html was not found" the check passes and you get a certificate. Oops. Now, not checking for a 200 OK was a bug, but even if you do check for 200 OK this validation clearly more of a polite "Keep out" notice to bad guys rather than any sort of actual defence.
So in the same period Let's Encrypt was being set up and ACME was being defined, the CA/B Forum also reformed the BR definition of how to validate DNS names using some of the same personnel. The result is the Ten Blessed Methods (although right now there are actually more than ten of them) and ACME is an automation of just three of those specific methods. Since then CA/B Forum has also worked on obsoleting the riskier and less useful methods and creating newer safer ones. Today that would be /.well-known/pki-validation/xyzzy.html safely in a reserved namespace, and it'd need a value inside it that's either entirely random or is determined by some other factor not under an attacker's control (in Let's Encrypt the equivalent string is a hash of the LE user's public account key).
Some of the Ten Blessed Methods are inherently kinda manual. Some just aren't very universal. So ACME and Let's Encrypt focus on the three which are most suitable for automation, surfaced in a way that is hopefully even more secure than required by the BRs and made available to everyone.