Memory is not getting freed on Destroy()

Question

Manager script(simple script attached to an empty GameObject on scene) on Start() instantiates 1000 default cubes with rigidbody component added and gravity check ticked.

public class SpawnScript: MonoBehaviour {

    public bool MakeInstances = false;
    public bool GC = false;
    public GameObject instance;
    public int numberOfInstances = 1;

    void Start() {
        if (MakeInstances)
            for (int i = 0; i < numberOfInstances; i++)
            {
                Instantiate<GameObject>(instance);
                //GameObject tempInstance = Instantiate<GameObject>(instance);
                //GameObject.Destroy(tempInstance);
                //tempInstance = null;
                //Debug.Log("obj is " + tempInstance);
            }
    }

    private void Update()
    {
        if (GC)
        {
            GC = false;
            System.GC.Collect();
            Resources.UnloadUnusedAssets();
        }
    }

Cube prefab have self destruction script like this

public class SelfDestruct : MonoBehaviour {
    public float seconds;

    IEnumerator DestructIn(float time)
    {
        yield return new WaitForSeconds(time);
        Destroy(gameObject);
    }

    void Start () {
        StartCoroutine(DestructIn(seconds));
    }
}

Profiler "simple" shows memory usage around 0.7gb after instantiating is done. I expect it to get freed after destroy, but it does not. Tried to apply GC and UnloadUnusedAssets, did not help. Tried to destroy them all right after instantiating, still no luck.
Is it a bug or am I doing something wrong? This is definitely not a real world example, just wanted to study memory management in Unity and got stuck here.

P.S.A few more strange points I have noticied with profiler:

1. In Editor/"Detailed" mode it would not notice that I have 1000 cubes on a scene, while in Build/"Detailed" it did
2. In "detailed"(both editor and build) data usage is around 200mb which is definitely not true(broken?), because Windows Task Manager shows me that build is using around 0.9gb. Bigger than what "simple" tells me, guess some overhead is present

EDIT:
Thanks to @Candid Moon for performing a test, he did confirm that software won't eat all the memory. Guess I should add screenshots with my observations Here we have no instantiation, simple clean scene with a plane, eats around 100mb Now let us go wild and make that instantiation on a startup

Alright, we did instantiate a lot of objects, they collided and flew away in outer space, in 5 seconds they were destroyed. We are back to clean scene with plane, just like the one with 100mb. Except for now it eats up 0.75gb. Left it hanging for half an hour to see if memory gets freed, nothing happened.
Is it a usual behavior? Is there any way to free all the used memory and go back to 100mb? Can/Should programmer do anything on his side to deal with such situations?

Answer 1

1000 isn't enough. I have taken your scripts and modified them a bit and it's showing that everything is working correctly. Instantiating 1000 objects gives you less than 1 mb - if you have seen any change it was impossible to spot it because of many factors like unity editor own objects and garbage creation. Calling GC doesn't necessary start the process (as far as I know - but I'm not sure about this one).

Here you can see how the memory is freed. Also, if it didn't free the memory I wouldn't have a constant memory usage when instantiating and deleting 100 cubes every frame. It would just gradually increase until I run out of memory. On these pictures I'm trying to show that the memory increases because we create many instances at once.

Memory went back to normal. If you create them at the same position the physics engine creates a lot of garbage because of collisions, so I modified creation on random positions.

Here you go:

public class SelfDestruct : MonoBehaviour 
{
    public float seconds = 5f;
    public double[] garbage = new double[12500]; //!!!!!!!!!!!!!!!!!! BE CAREFUL - IF your computer is slow and you attach this script the array will be so big to display that UNITY MAY LAG. TRY TO DECREASE THIS IF you experience freeze

    IEnumerator DestructIn(float time)
    {
        yield return new WaitForSeconds(time);
        Destroy(gameObject);
    }

    void Start()
    {
        StartCoroutine(DestructIn(seconds));
    }
}

public class SpawnScript : MonoBehaviour 
{
    public bool MakeInstances = false;
    public bool GC = false;
    public GameObject instance;
    public int numberOfInstances = 1;

    private void Update()
    {
        if (GC)
        {
            GC = false;
            System.GC.Collect();
            Resources.UnloadUnusedAssets();
        }

        if (MakeInstances)
        {
            for (int i = 0; i < numberOfInstances; i++)
            {
                Instantiate(instance, Random.insideUnitSphere * 300f, Quaternion.identity);
                //GameObject tempInstance = Instantiate<GameObject>(instance);
                //GameObject.Destroy(tempInstance);
                //tempInstance = null;
                //Debug.Log("obj is " + tempInstance);
            }
        }
    }
}

I didn't call CG even once during testing. Only in the end to try if anything changes - result is nothing has been changed.

Conclusion: Destroy works as intended and it frees up the memory. Other problems might be in physics or something else. Coroutines were used as well, so they don't seem not to free up the memory usage.

EDIT

Now if we look at profiler.

---

We can see that profiling data stacks memory. And if you try to profile yourself you will be able to see how many objects in scene you have right now and if they are being destroyed and if the memory is freed.