I think your question is not really specific to R, the same issue often arises when a group of teammates has some code to share amongst them, written in whatever programming language they use. With a growing amount of code, they reach the point where they have to consider if they just keep sharing it by loosely throwing it together into a common folder, or if they are going to use a more rigid standard packaging or library mechanism of the language (at least, for parts of the code base).
The answer to this question is: "it depends". Using standard packaging mechanisms has several benefits concerning
they provide a standard for versioning and dependency management
they provide standard for documentation and API description
you shift dependencies from the "per function" level to the "package level", which reduces the number of dependencies heavily and makes them more manageable
the mechanism may provide other standards like how to structure the code, the tests, the documentation, etc.
Ideally, this should make it easier for the team to reuse the code.
On the other hand, you never get this for free. When you start building packages, you need to introduce a maintainer for each package, someone who is collecting the source code for the package (and if necessary, makes some editorial changes), who decides what goes in there or what not, who assigns a version number to the package, and who knows the technical side of the package mechanism in-depth. The package code will probably need to fulfill a higher formal level of quality than unpackaged code (for example, additional docs and tests).
So, if you want to know if your team already reached the point where the benefits outweigh the extra effort, you cannot simply decide this by comparing "30" vs. "60" scripts. It depends on factors how many people are involved in your team in writing and providing scripts, how many reuse them, how often do changes occur, do people in your team have problems finding existing code for reuse, problems to understand how to reuse a specific function, problems on resolving dependencies, and so on?
So if your team does not have any problems with the current approach, don't do anything for now. If, however, you see at least some of the problems, but are unsure if packaging will solve them, I suggest to simply try it out. Put some of the current code, most heavily reused code into a package, publish it in your team and see if the benefits are worth the overhead for your team.