As a Roblox developer, storing objects on the client is currently inconsistent and un-intuitive, and not able to be customised per player.
There are a variety of ways where objects (that need to be accessed by different scripts) can be stored. You can put them in the Player object or one of its children, or into ReplicatedStorage, or other weird places like (god forbid) _G. In a nutshell, you can store stuff anywhere that doesn’t replicate to the server. This is not good, primarily for two reasons: consistency and performance.
In terms of consistency, the answer to the question of ‘where stuff goes’ varies based on the developer answering it. Games made up of different peoples’ work (when they are uncoordinated) are messy in lots of ways, including client-side storage. There’s no ‘right way’ to store things client-side, either, leading to unnecessary decision-making by developers and third-party resources (e.g. open-source libraries) that use different methods/places of storage. Having a single, official place to put stuff allows for developers and resources to be consistent with each other and the things they are being applied to.
In terms of performance, inexperienced developers may be using inefficient or outdated methods of storing objects client-side (such as _G). Having a single, official place to put stuff allows for game performance to be increased and good habits to be learnt in the context of beginner developers.
Another thing is that, currently, there is no proper way to replicate objects to specific players. For example, if I have different versions of a map for different graphics settings, there is no good way to send only the appropriate assets to each client. Having some way to interact with a specific client could be really useful.
There are also lots of small issues like having to constantly type out long paths at the start of scripts (to get to wherever your client-side storage place is), ReplicatedStorage being messy due to handling both replicated and non-replicated objects, and the design question: ‘why do we store stuff that doesn’t replicate in a place named ReplicatedStorage?’
To summarise all of the positives of a solution:
- Allows for developers and resources to be consistent with each other and the things they are being applied to.
- Allows for game performance to be increased and good habits to be learnt in the context of beginner developers.
- Having a single, official way to interact with a specific player’s storage could be really useful.
- The small issues mentioned above will be resolved
Credit to @Zomebody for some extra ideas for what this may be used for.
Thank you 
Personal suggestion
A solution I came up with while writing this post is two services. These services would be ClientStorage (client/‘unlisted’ but existing on server) and StarterClientStorage (server).
ClientStorage would essentially act as a copy of ReplicatedStorage, however it would be named differently, and be unique to each player. While you’d think the solution would be to make it work like ServerStorage, it can’t due to the server also needing to interact with it. On the client, it’d be retrieved using game:GetService("ClientStorage").
StarterClientStorage would act similar to the other Starter services. Its children replicate into every player’s ClientStorage service/object.
It would have a method that you could use like this to get access to a specific player’s client storage object:
local PlayerStorage = game:GetService("StarterClientStorage"):GetClientStorage(Player)
Theoretically, this shouldn’t be hard for beginner developers to learn, as all they will really need to know are two things: You can put ‘default’ objects in similar to the other Starter services, and you can get the Storage client-side using GetService("ClientStorage"). Simple.