TL;DR: Don't bypass the restrictions imposed by firebase on the application you develop. Although by default firebase doesn't allow you to change these values afaik, you have the options to create a custom e-mail template and a flow and "add" the tweaks.
Firebase "verifies" the user before creating a session by something the user know and another thing that user has. In this case e-mail and the link the user received in order.
In traditional approach, this is username and password.
If you put the "e-mail" information in to the object the user supposed to have, you reduce the factors from two to one.
And also if you let user to reuse the same object instead of unique asset that is generated every time the user intentionally request, you further reduce the security.
Take this examples:
Developer generates a sign on link that is reusable and e-mail address embedded. And user goes on and pastes this link somewhere public. In this case anyone clicking on the link will log on as the same user.
Developer generates a sign on link that is only reusable. User pastes the link to a chat application where others can see or guess its e-mail. With minimal effort, others will be able to log on as the same user.
The document just explicitly warns the developers to not bypass or workaround the restrictions imposed by firebase as you mentioned.