My recommendations would be:

• Do not rely on GC.Collect() in any real program code. Just let the GC do its thing.
• If you need guarantees about when the destructor (or equivalent) is called, use the dispose pattern and use a using statement or declaration explicitly so Dispose gets called as soon as possible.

class DestructorDemo : IDisposable
{
    public string Name { get; set; }
    public DestructorDemo(string name)
    {
        Name = name;
        Console.WriteLine($"demo object {Name} constructed");
    }
    public void Dispose()
    {
        Console.WriteLine($"demo object {Name} disposed");
    }
}

using var obj1 = new DestructorDemo("obj1");

using (var obj2 = new DestructorDemo("obj2"))
{
    Console.WriteLine("Press key to dispose 'obj2'");
    Console.ReadKey();
    // obj2 goes out of scope at the end of the block
    // this will automatically call `.Dispose()` on it
}

Console.WriteLine("Press key to dispose 'obj1' and exit");
Console.ReadKey();

// obj1 goes out of scope here

Note that this code is just to showcase the using keyword (in relation to IDisposable). If you want to implement the disposable pattern properly you should look at the help article I linked. Such as making sure that Dispose is called even if the object is naturally garbage collected, that is if you forget to use using. (I also didn't check the validity of the code but it should get the idea across.)

Relevant article: https://ericlippert.com/2015/05/18/when-everything-you-know-is-wrong-part-one/

Long story short, whoever wrote that tutorial is wrong: you cannot guarantee invocation of finalizers. My guess would be it's old and maybe used to work, but the inner workings of the GC have changed since then.

OTOH gc might decide not to collect it immediately since it's in a static method, try this instead

DestructorDemo? obj1 = new DestructorDemo();
//Making obj1 for Garbage Collection
obj1 = null;
for (int i = 0; i < 10; i++)
{
    GC.Collect();
    GC.WaitForPendingFinalizers();
    obj1 = new DestructorDemo();
}

You'll see destructor in action.

Far more familiar with Java since I've mostly used that the last decade, but two questions come to mind...

1. Does the console object buffer output? I know you're waiting for a key, but sometimes buffers do weird things like not flushing when you expect.
2. Is GetType failing silently? I'm not familiar with the innards of C# any more, but in rare occasions in other languages, errors/exceptions get silently swallowed. Usually it's with funky code that amounts to a logical error and not a true magically swallowed exception, but...

At least GC.Collect() is a blocking collect, but perhaps there could also be funky shenanigans happening? I'd also think it'd collect obj1, but it is still in the same scope it was created in. Maybe there could also be some funkyness there with objects only getting picked up if they're out of scope or similar?

I'd imagine most of the above would be really easy to test if you can get a debugger to step through. If it doesn't hit at all, something odd is happening with flagging the objects for collection I'd think. If it hits but errors, easy peasy. If it hits and executes fine but doesn't show, maybe as others suggested, use a different function rather than something from Console or something?

Some ideas:

It's been a long time since I used Java and C# but you were not supposed to write destructors, or "close objects" improperly by setting a null value, or calling collect explicitly.

Also you're blocking the application with ReadKey to trick the terminal into keeping the window open. That could prevent the GC from working at this specific step because the main function is not over yet. Configure the IDE instead to keep the terminal open, and remove ReadKey.

Calling collect is only a piece of advice to the GC, it could wait after you press the key but you wouldn't see it if the terminal closes too fast.

Try with Trace.WriteLine instead of Console.