needs to be rebased once#28712 is merged up to master

I'm really unsure about this. Having an option means asking devs to make a choice, and making a choice is hard. Here, enabling strict mode (Yay, strict all the things!) means lowering the compatibility with the ecosystem. That's contra the robustness principle.
We have a native date parser that is excellent at parsing real-world date formats, there is no better option for me. We should leverage it.

To me, this goes along with#28753. If one wants to use HTML 5 features, they should follow the standards IMO. Custom formats are okay, but then you need to be explicit about this (i.e. sethtml5 tofalse and configure theformat option explicitly). Without being strict, there is too much room for guessing from my point of view which unnecessarily adds uncertainty that makes it hard to fix any date (and time) related bugs.

@nicolas-grekas if you have a form type configured as HTML5_FORMAT, supporting other formats looks weird.

The option is here to opt-in for the new behavior at the time you want (needed in case your JS currently generates a different format for instance)

We may also want to harden DateTimeToRfc3339Transformer to actually support only RFC 3339 (usingDateTime::createFromFormat)

I'm 👎 here: data transformers are not where strictness should apply. Strictness is for validators.
My reasoning is "why?" should we make this change? What would it improve? On the maintainer side, nothing. On the user side, it would just make using the HTTP endpoint less compatible with UI widgets into the wild, thus making things harder to use actually.
Same as why XML didn't win the race and browsers are using a loose HTML5 parser for the benefit of the robustness of the Web.

@xabbuh ok with my main objection: not worth adding a new option as DX may suffer?

I am closing here for now. We can consider to reopen when we notice that a less strict date format handling leads to avoidable bugs.