Collections are containers for documents. Whether you put a document in collection A or B makes no difference to the cost of storing the document.
You could put all sorts of different kinds of documents in a single collection; there is no built-in mechanism to enforce types in FQL, so there’s no restriction on the kinds of documents that can coexist. For GraphQL, there is type enforcement as part of schema processing, and by virtue of having a User type and a File type, there would be two collections.
When you combine different kinds of documents in a single collection, there is some overhead to distinguishing between the different documents. If you want to search only for user documents, your indexes would need to implement one or more bindings that would determine which document should be indexed. With separate collections, the structure of indexes would be simpler, and involve fewer compute operations.
In terms of relating users to files, that’s something you would need to do regardless of the organization of the files. If a user can be associated with a small number of files, you might maintain an array of file references within each user document. If the cardinality of user->file associations is high, this would typically be done with an intermediate collection containing documents that include references to user documents and their associated files.