It makes a lot of sense to decouple parsing from the rest of the compiler, if only purely from an engineering standpoint.
Editors, IDEs and other tools (transpilers, linters, formatters) already have to reimplement the parser, or at least hook into some API. Having them interact directly with the AST is a huge bonus. Sure, you'd have to rewrite your diffing algorithm to use a tree, but it seems minor compared to the cool things we'd get.
As long as you have a sane AST specification (the HARDEST part, IMO) you'd be able to have teams with people working in a Python-like syntax, others working with a LISP-like syntax, and so on, as long as internal semantics are the same (again, the hardest part).
Instead of having thousands of crappy compilers we'd have pluggable parsers emitting ASTs. This is much better for experimenting with Developer Experience and trying out new things.
Even the typing system could be decoupled: adding a borrow checker or dependent types wouldn't require writing a new language or forking an existing one, so they would be reusable, as long as the AST supports it. Running a linter during a compilation process would also be trivial.
And we would be able to reuse optimizations, code generation, interpreters.
We complain so much about "vendor lock in" but this has potential to remove the language lock-in that we have. Sure, we'd still be able to get locked-in to frameworks and libraries, but that's something to solve another time.
--
OT: I actually had a similar experience back in the 2000s when we had to convert a large VB.NET codebase to C#: we used the first crappy "convert VB.NET to C#" site we could find online and it did the job amazingly well. Fun times.