The whole point is to make sure that your tests are isolated and data required or generated by a test, won't affect the result of a different test.
Re-creating the schema gives you this guarantee because each tests will start with a clean database.
That said, the creation/drop of the schema is a pretty heavy operation, and the more tests you add to the test suite, the slower it will become.
The drawback is that you need to make sure that the data is cleaned after each test. This might not be too complicated to achieve in practice (you might need to pay special attention about different entities in different tests mapping to table with the same name) but if you are working an a small project or your database is really quick updating the schema, it might not be worth the hassle.
It's up to you to decide what works for your project.
As a practical example, in Hibernate Reactive we need to run the same tests on several different databases. We started re-creating the factory for each unit test, but because running tests was becoming too slow (especially on some databases), we've switched to re-creating the factory once for each test class. It helped us to save a lot of time because tests in the same class became so much faster.
In the end, you need to decide how your test suite is organised and the benefits of one approach over the other. But as long as you are reasonably sure that the tests won't affect each other, you can use the solution you prefer.
