Depends on your later usecase, as always. It is also a classic topic that is discussed by all general database literature and has nothing to do with spatial databases. Things to consider are normalization, privileges, indices, foreign keys, constraints and stuff.
But there are two things to consider for the given example as it sounds that the db is just used for local data storage.
Try to not store data in different databases that are somehow related. Selections across multiple databases is possible but not as fast as within the same db. Also the selections are more complicated. Second thing is that you have to use seperate database connections in any program you want to use this data. That is not very user friendly.
Schemas are also used to seperate data that usally is not close related or to manage privileges and different versions. Most databases I know also store everything in public as some software does have problems with other schemas. In honor of Vince's comment I have to admit that this is not a good practice but an often used "quick and dirty" solution. If your project should become more than a local storage avoid this laziness.
Set all privileges in the beginning whenever the database should become more than a local solution on your machine. Keep in mind that the "public" schema and user is special in Postgresql and the it has its own privileges. Read the chapter in the documentation. Also set all table and column names to lower case letters. Some software does not handle upper case well as they do not use the selections properly. ("public"."Test" is antoher table as public.Test)