Generalized VS Specialized technical solution; what to take into account?

Question

We recently had a discussion in the office because of conflicting views between developers. One side (side S) argued technical solutions -generally- need to be a specific as possible, while the other side (side G) argued generalized solutions are preferred.

I'll try to keep it short; we deal with file transfers and we need to start saving three files (log.txt, details.txt, receipt.pdf) for each transfer. We already have a files table that we'll use but we all agree that we need a different table to create a one-to-many relationship between transfers and files.

Side G proposed creating general resource_attachments table that can attach files to any type of resource it would look something like this;
resource_attachments
- id : int
- entityId : int
- entityType : string
- fileId : int
- kind : string

Side S disagreed and proposed creating a specialized transfer_attachments table, something like this;
transfer_attachments
- id : int
- transferId : int
- fileId : int
- kind : string

One argument of side S is that any resource should be as specific as possible so its role and its attributes and their possible values are clear, so any new developer will have no trouble understanding it.

An argument of side G was that a more generalized approach would provide a broader range of functionality; you can attach files to any resource, whatever their role will be.

Though the practical differences are very small, there is some fundamental stuff going on here (this is where it gets philosophical); one person in the room sharply observed that the generalizer is the ruby expert, while the specializer is the java expert. Ruby is an interpreted language with dynamic typing while java is a compiled language with static typing.

I found the matter wildly interesting and was wondering which approach is preferred; specialized or generalized solution, and what matters should be taken into account?

Note that we're only talking about a the technical part of the solution, this has nothing to do with the end-user experience.