https://qiita.com/dossari-book-archive/items/ad4f7bcaaebca6281154
ここを読んで、既に該当部分は消えてたんだけど、コメントで漸進型付けが推されていたので気になった。
PHPの場合は他の言語と違って、厳密さや保守性のために型を書くのではなくて早く作るためとか楽をするために型を書く場合が多いんじゃないかなーと思う。

auto wiring については
http://blog.tojiru.net/article/444541164.html
ここが分かりやすい。
ここに書いてある通り、Javaのやり方でインターフェースを書いたりしても微妙で、面倒になることの方が多い気がする。

PHPのDIは

class MyActionController
{
  public function index(Request $request, FooModel $fooModel)
  {
    // ...
  }
}

と書いたら何も設定していなくても自動的にRequestやFooModelを持ってきてくれるという使い方で、別にインターフェースを利用した多態性のためにやっているわけではない。（フレームワークやライブラリの開発者でなければ）

class FooModel
{
  public function __construct(Db $db, BarModel $barModel)
  {
    $this->db = $db;
    $this->barModel = $barModel;
  }
}

FooModel のコンストラクタがこんな感じになっているとすると、これも自動設定される（DI？）。BarModel の…という感じで連鎖的に次々自動設定される。自動設定のための設定ファイルは特に書かない。
大抵のフレームワークやコンテナはほとんどこの機能があるのではないかな。
Javaだともうちょっとインターフェースや依存関係をしっかり設計しようという気になるけども、PHPは実装クラスをそのまま持ってくる。インターフェースはあまり使わない。
他の漸進的型付けを扱う言語ではこういう使い方はしないよね？

まあauto wiringを使わない関数でも型を書いて静的チェックをすることもあるけど、静的チェックをしない人でもauto wiringはフレームワークが用意しているので知らずに使ってる場合が多いのではないかなという印象。

PHP7.4 で Typed Properties が入ったら、リクエスト変数のidからクラスプロパティのDB Entityクラスを自動設定しやすくなって、ますますauto wiringが捗る予感がする。

例えば、動的型付けなのに、静的型付けで扱うようなインターフェースを導入する思想が自分には理解できません。

この意見には基本的には賛成。例外は、PHPではフレームワークやライブラリが乱立する傾向にあるので、その乱立したフレームワークが共通のインターフェースを使ってくれていると混乱せずに済む。
プロジェクトの中で使う分にはあまり役に立たないけれど、各FW同士の多態性という面では役に立っている。