/shared is not a good folder location as this breaks FHS. Thereby the package gets unfit for inclusion in most distributions. It’s a new folder that is easily forgotten during backups.
It’s a question what do we optimize for?
Principle of least astonishment (POLA) is a good one.
Follow FHS? That’s a good one too.
Optimize for usability? Not necessarily an optimization problem.
Reading FHS again chapter /home. Relevant quotes…
/home is a fairly standard concept, but it is clearly a site-specific filesystem. 
 Different people prefer to place user accounts in a variety of places. This section describes only a suggested placement for user home directories; nevertheless we recommend that all FHS-compliant distributions use this as the default location for user home directories.
On smaller systems, each user’s home directory is typically implemented as a subdirectory directly under
/home , for example
/home/operator , etc.
On large systems (especially when the
/home directories are shared amongst many hosts using NFS) it is useful to subdivide user home directories. Subdivision may be accomplished by using subdirectories such as
/home/students , etc.
I guess the sandbox use case is closest to “large systems” use case.
/home/sandbox seems appropriate.
sandbox- is superfluous. )
Therefore advise can stay “backup your home folder”. Meaning not /home/user but meaning backup /home.
That seems to be close to FHS and also be good for usability. Better than /var/lib/sandbox which is a lot harder to remember and backup. Contents of /home are more easily discovered than /var/lib.
Also /home/sandbox/shared or something would be good. But then we must make sure that no app can be named “shared”. 
Thinking for restricting user
user, could a compromised user
user mess with
app_name and make an app that shouldn’t access another apps data?