https://bugs.python.org/issue19660 is a more in-depth discussion of a proposal to drop the restriction.
Actually doing so would require a PEP, since it’s a syntax change, and the biggest challenge faced is that most of the currently disallowed cases end up being more readable when they’re refactored to turn the decorator expression into an appropriately named function.
The context where the original syntactic restriction was imposed was one where the existing code pattern the new syntax was intended to replace was either:
my_method = classmethod(my_method)
my_function = some_decorator_factory(*some_args)(my_function)
So the original syntactic restriction had the effect of making it more obvious which cases of function post-modification were suitable for refactoring to use the new more declarative decorator syntax, and which should continue to be handled as imperative post-modification. It also had the benefit of almost entirely eliminating the risk of cryptic one-liners that overshadowed the trailing function definition as a potential point of concern. So while the PEP specifically cites Guido’s post about it as BDFL, he was far from being the only one concerned by the prospect of folks getting carried away with overly complex decorator expressions, and it turned out that having to nest things inside a no-op function call was enough of a hint to get folks not to do that kind of thing.
The situation today is different, in that we have a decade-and-a-half of experience with the restricted syntax to set the precedent for what “reasonable decorator syntax usage” looks like, and a couple of currently disallowed cases where readability would remain quite reasonable (i.e. using subscripting instead of a function call, doing an attribute lookup after the function call).
So while a PEP to change this would still face a lot of challenges (since any grammar change has a non-trivial implementation cost not only for the reference interpreter, but also for developers of other implementations and tools that are sensitive to the exact language grammar), it would have a chance of success if it was able to identify cases where a suboptimal API design was chosen to fit within the constraints of the decorator syntax, even though there were other options that would have been more readable (or equally readable with less code complexity) if the syntax had permitted them.