I want to get some more perspectives on this; I expect different opinions from you all. I'm not so comfortable talking on the subject to make a strong case either way.

Everyone's gotta do it the way they seem is right, I just wanted to warn this person of the potential obstacles this might create as the game/codebase expands. Maybe after all this method has good trade-offs.

Normally, I don't watch linked videos at all. I made an exception and it was not worth it.

Don't get me wrong, normally, I'm all for "no limits for the programmer who knows what he's doing", especially if it's your personal project. But this seems to be overdoing it even for my generous tastes.

a) "Vectors"
Why reinvent the wheel with his arrays when he could just use std::vector?

He said it was for educational reasons and "that is was a really interesting way to do it".
Well, it probably is if you never did something like that, but I'd rather not recommend it as a general technique.

Seems like he learned OOP first and now discovers low level stuff. For me, it has been just the other way round, I did much C-only programming before moving on to C++. The one thing I've learned to appreciate very quickly were C++'s STL container classes. They're not perfect, but standardized and generic.
If there's a valid reason not to use them, you can still do so, but generally avoiding them just seems to ensure you don't get the benefits.
I also notice he's using C-strings there which ... could be more easy to manage (I wonder if he even frees them appropriately?).

b) Unions instead of inheritance
Advocating the use of unions this way just feels very wrong to me and I generally wouldn't recommend it to anyone except you have very good reasons to (e.g. wanting to have objects with the same size (again, for a good reason)). As long as the values are of the same type, it is less dangerous, but you basically loose type safety and can only use it for POD types. That's not very flexible and can be outright dangerous.

"No need to cast between derived types"? I cannot imagine a sensible situation where you would want your rectangle (l, w) be "reinterpreted" as a triangle (b, h). If I don't overlook something here, it's just a non-argument. Again, you loose type safety. I'd say it's nice to know for you, as a programmer, what your dealing with by being able to read your code semantically. You seem to loose that as well.

Note that with all that POD-stuff and manual memory-management, you further loose the ability to have (sensible default) c'tors and d'tors. It's a very convenient C++ feature that you can create objects as values on the stack and their c'tors and d'tors are called appropriately (when going out of scope).

c) enums instead of dynamic_cast
Who said the only alternative to an enum was dynamic_cast?
You can static_cast pointers and references just fine if you know what type you have (for example, by using an enum to encode types...)
You certainly do not need the union part for that.

Besides, especially on today's hardware, virtual function calls are certainly not the first thing to worry about.

d) Whole GUI done like that
Well, as bambam has already pointed out, I don't think it's very extensible (or readable).

Apart from that, I don't think OOP is the general answer either. Just try to use the right tool for the job. I'd say a GUI is one of those areas where OOP seems to make sense?

Generally, learning and experimentation are always a good thing, though. I'm personally not so convinced of making all of this process public.

Edit:
This reminds me of the day I talked to a new programmer who had mostly learned Java. He was in the process of familiarizing himself with C++ and somehow seemed to be very enthusiastic about "what you can do with void* pointers". Not everyone shared his enthusiasm.

I prefer polymorphism over his unions.

What about a simple get_area function? Creating a separate sub-class for each shape, would take longer but be cleaner and easier to handle.

class Rectangle : public Shape
{
..
float w, h;

float get_area() { return w*h; }
..
};

With unions, it makes for one big function.

float get_area()
{
// some switch statement or multiple ifs
if (type == RECTANGLE) return {w*h};

If you happen to add a shape, you'ld have to go through and modify each function. Messy.

The specific advantage of union is that it allows you to change the type of an instance at runtime : Allocated elements always take the same amount of memory, so you don't need to reallocate, it means you don't have to track down every pointer to the element to update them.

AFAIK, there will be type-safe std::variants in C++ 17.