Should my Json storage handle exceptions?
This is how I see things...


Throwing ArgumentException insinde a try/catch that at the same time swollows it is pointless. You use ArgumentException to inform the user that he called your API in a wrong way. This is not something one should hangle because he won't see it until he looks at the logs. The app should crash in this case.
The message of the ArgumentException is too generic. When it happens, the user already knows something is wrong. Tell him how to fix that by giving him a hint what the correct path should be and what path he actually used.
The way you are handling exceptions that might be thrown by the json-serializer is unexpected (non-standard) because the user will wonder why he got a null without noticing anything. public library APIs should always throw unless they are called TryDoSomething and return a bool.
Yet another flaw of this pattern is that it doesn't help anyone to find the source of the exception. You neither add the filename to it nor the object that it tried to de/serialize. This is very important piece of information and should be included. 


So, what you can/should do instead is to throw a new exception that adds more information about what happened e.g.:

public T RestoreObject&lt;T&gt;(string path)
{
    if (!fileSystem.Path.IsPathFullyQualified(path))
            throw new ArgumentException($"Invalid path: '{path}'. It must by fully qualified.", nameof(path));

    try
    {    
        string json = fileSystem.File.ReadAllText($"{path}.json");
        return JsonConvert.DeserializeObject&lt;T&gt;(json);
    }
    catch (Exception ex)
    {
        throw new JsonStorageException($"Could not restore object '{typeof(T).Name}' from '{path}'.", ex);
    }
}


You'll be happy to see the type and file name when something goes wrong.