The main problem for cross input aggregation is that normally you can just soft-fork in new signature types (e.g. including new sighash types) just by creating a new checksig operator (or having a pubkey of a different length).

But a new signature type added in a backwards compatible softfork couldn't be aggregated with other signatures even if the underlying crypto is the same.  This is especially relevant because there is a current interest in adding some new sighash types, also graftroot which is also effectively a new sighash type.

Aggregation could have been done for basic taproot alone, and then any new types would have to be separately aggregated... but probably along the way we'd come up with different optimizations in how aggregation works, and then the consensus rules would have two implementations of aggregation. Worse, if taproot originally has aggregation people will probably upgrade slowly to a later tapgraftroot since mixed transactions would have higher overhead from the inability to aggregate them both, and fungibility would be hurt by the slow upgrade.

There are also some ideas that could allow for better backwards compatibility.  In particular,  if a new witness-like p2p extension were made that allowed transmitting the concrete sighash values as witness data to old nodes that don't know how to generate those sighashes (but otherwise not keep them in blocks),  then aggregation could be preserved even with future softforked in sig hashes.   But witness-like p2p extensions are a real pain to design and deploy, and no one seemed particularly eager to do that work right now. If one is done it should probably pick up some other improvements other than just backwards compatible aggregation.

So essentially, aggregation is conceptually ready but there are very strong incentives to deploy it in combination with other features which are not currently ready.  Trying to do everything at once is just too big an engineering project to pull off safely, and we're likely to learn a lot from actual usage of taproot which would help improve the design of other features (particularly of graftroot/g'root).

Right now I don't think the current amount of engineering interest in Bitcoin is particularly healthy.  Many long time contributors, including myself, have essentially stopped contributing for a variety of reasons (including uncertainty around political disruption of deploying even fairly boring new consensus changes, concern that too much bitcoin hashpower is controlled by bitcoin adversarial parties who would attempt to block protocol improvements, etc. on top of more generic factors).  Lightning is also easier, faster, and often more interesting to work on and so it has diverted a lot of new blood.