Previous PL researcher here. There are a few reasons for this.
First, it's important to distinguish between "positive" features and "negative" features. "Positive" features are where you can do additional things you couldn't do before. I'm guessing your AmpLang is primarily about positive features? Researchers do implement these as libraries or DSLs. For example, the most influential paper in pretty printing is Wadler's pretty printer, which is implemented as combinators in Haskell.
However, a lot of research is on "negative" features, where the compiler or type system gives guarantees that certain bad things can't happen. You can't usually add to a language and get negative features. For example, this post's paper is in the "negative" category, so it wouldn't make sense to develop it as a DSL, and furthermore it's about static type systems, so it wouldn't make sense to use anything like Python. Also, existing languages are huge, and when you're doing proofs, you need to fully model the language you're proving things about, so papers would get vastly more complicated if they tried to build on top of an existing language. Instead, the usual approach is to develop a teeny tiny boring language that also has the new feature (in this case, the new type system that handles concurrency).
Another thing to realize is that most "languages" in research papers aren't meant to be used. Success for such a language doesn't mean that people start using the little prototype they built (if the language is even implemented); instead success means that someone transfers their ideas into a new or existing language, and builds all of the tooling for that language. The hard problem that the researchers are solving is proving things. This is very hard! Real languages (especially type systems and compilers) are built on top of decades of language research! But it's very different from developing all of the libraries and tooling for a practical language, which is an entirely different process.
First, it's important to distinguish between "positive" features and "negative" features. "Positive" features are where you can do additional things you couldn't do before. I'm guessing your AmpLang is primarily about positive features? Researchers do implement these as libraries or DSLs. For example, the most influential paper in pretty printing is Wadler's pretty printer, which is implemented as combinators in Haskell.
However, a lot of research is on "negative" features, where the compiler or type system gives guarantees that certain bad things can't happen. You can't usually add to a language and get negative features. For example, this post's paper is in the "negative" category, so it wouldn't make sense to develop it as a DSL, and furthermore it's about static type systems, so it wouldn't make sense to use anything like Python. Also, existing languages are huge, and when you're doing proofs, you need to fully model the language you're proving things about, so papers would get vastly more complicated if they tried to build on top of an existing language. Instead, the usual approach is to develop a teeny tiny boring language that also has the new feature (in this case, the new type system that handles concurrency).
Another thing to realize is that most "languages" in research papers aren't meant to be used. Success for such a language doesn't mean that people start using the little prototype they built (if the language is even implemented); instead success means that someone transfers their ideas into a new or existing language, and builds all of the tooling for that language. The hard problem that the researchers are solving is proving things. This is very hard! Real languages (especially type systems and compilers) are built on top of decades of language research! But it's very different from developing all of the libraries and tooling for a practical language, which is an entirely different process.