Schemaless is a misleading term:
On one side, a SQL database always has a well-defined schema. This schema is fixed. If you want to put more information in a "record", you'd have to alter the database structure to add new columns to a table.
On the other side, a document oriented database like MongoDB has no predefined schema: every document inserted into a collection can have a different structure. You can literally save apples and organges together: the DB won't care.
But the truth, is that despite a MongoDB collection could contain anything, in practice there is always some kind of structure in it. Schemaless therefore is rather to be understood as a dynamic or flexible scheme, that does not need the database to be altered to cope with evolutions.
In this context, a schema can be defined for validating documents. This allows to combine the benefits of both worlds:
- you can define the minimum requirements for a document, for example that a student document must have at least the first and last name since this information is needed by your applications in every display window to designate which student it is processing.
- you leave all the desired flexibility for the other fields and for evolution of the scheme.
So the use of a schema implies a good practice.
Conversely, not using a schema implies that the documents in a colletion could be complete garbage. In some applications, this could be without consequences. But for general business applications, it sounds more like a bad practice.
Of course, you could reduce the impact of such practice by controlling upfront the structure of the documents you insert. But this would transfer the responsibility to the application and might not prevent that other applications do not comply with the requirements.