A team where the Engineering Lead(or any kind of manager) thinks that you don't need retros because there are no problems is exactly the kind of team that needs retros.
My experience is that most retros result in a list of things that should get addressed but never get addressed. Especially because they must be addressed by larger organizational changes once the low hanging fruit has been addressed, In teams where we actually addressed these issues we ran out of things to say in the retro after a few times.
Things being recognised and never/rarely acted on is better than them going unrecognised entirely. At least in the former scenario, there's a shared awareness of the problem.
This is a situation that really depends on the team. If your team isn't surfacing issues, then either you're creating an environment where people don't feel comfortable surfacing issues, or your team is mostly just not the type that is proactive about it.
If it's the latter, then "priming the pump" is a useful exercise, and a regular retrospective makes tons of sense.
That's also generally true of processes: every team has its quirks, and you fit the processes to the team's quirks.
Meh. A team with a leader/manager like that isn't going to get much value out of retros because either the leader/manager isn't going to listen to what's being said, or everyone won't feel safe enough to be able to say what needs to be said.