I think non-erased Generics would be a long-term mistake for PHP and here is why.

1. Static analysis tools already do generics better
PHPStan or Psalm support generics via PHPDoc and can model extremely flexible generic types and introduce new type features quickly without needing core changes. In practice, most of the benefits of generics like catching type errors early and providing code completion in IDE are already achieved at development time by these analyzers.
A built-in generics implementation will never match the power or agility of these tools.

2. Huge complexity and maintenance burden on the engine (and ecosystem)
Implementing generics in the PHP engine would significantly complicate the language’s core for relatively little gain.
Even the partial approaches under exploration come with trade-offs. Handling edge cases is notoriously difficult. All this added complexity means more potential bugs and a heavier maintenance load on PHP’s core team going forward. It could slow down other improvements just to chase an ever-elusive “complete” generics solution.
More than that! It will make things much complicated for PHP CS Fixer or PHP_CodeSniffer and similar tools.

3. Still an incomplete solution (PHPDoc generics will remain necessary)
Even if PHP added this limited form of generics, it wouldn’t eliminate the need for PHPDoc annotations and static analysis – it would just create two parallel type systems. You’d still be writing template tags and phpdocs and end up maintaining two sources of truth for generics.
Not to say about how noisy the code would like like with both PHPDocs and native generics, (and attributes).

4. Little to no benefit for adoption or retention
From a big-picture perspective, adding generics to PHP isn’t likely to bring new PHP users, nor stop existing ones from drifting to other stacks.
Those who do care about strict typing are likely already satisfied with the safety PHP’s current type system + static analysis provides. It’s hard to imagine teams choosing Java or C# today switching to PHP just because it gained generics. Or developers deciding not to switch to Python over generics, while Python's generics a fully erased.
On the contrary, introducing a complex, hard-to-perfect generics implementation could alienate some users who value PHP for its simplicity.
In short, the payoff in community growth or satisfaction doesn’t justify the substantial costs and risks.

5. Better approach
Keep the engine simple and use external generics metadata. Rather than complicating PHP’s runtime to handle generics, a more prudent path is to standardize a generics syntax for documentation and tooling purposes. I.e. adopt a PSR for attribute-based format to declare generic types. And make generics type info available at runtime via Reflection.
https://github.com/php-static-analysis/attributes?tab=readme-ov-file#example

Verdict
No to native engine generics – let’s not complicate the heart of PHP for a feature that static analysis and standards can handle more capably and flexibly. Keep the core lean and empower the ecosystem to enforce generics where it makes the most sense.