Partitions and filesystems are not the same. At no point the filesystem was destroyed.
Partition is just a part of a larger device identified by some entry in the partition table. fdisk manipulates this table. In DOS (MBR) partitioning scheme partition table is at (strictly: near) the beginning of the disk. In GPT it's near the beginning and (another one, backup) near the end. It doesn't belong to any partition, at least it shouldn't. In some sense you can think of it as "a table of contents".
Filesystem is a structure that usually lives inside a partition (but it may live in a regular file or take the entire device). Even if the partition entry is no more, you can mount the filesystem if you know its offset.
The author of the video destroyed the partition entry and created a new one. This only affected the partition table, not the actual data within the (old or new) partition, i.e. the filesystem. The partition in question was recreated larger but its starting sector remained. This is where the filesystem starts.
After the reboot the filesystem mounts successfully, because the kernel looks for its header at the beginning of the new partition, which is the same as the beginning of the old partition where the actual filesystem header was/is. The filesystem knows its size, so the fact the partition is now of a different size is irrelevant, as long as the filesystem "fits" (so enlarging is always OK; see the note about shrinking at the end).
Finally resize2fs was used to actually resize the filesystem. The new size was not specified, so the tool let the filesystem take the entire partition. This was the only moment anything was done to the filesystem itself (aside routine mounting and accessing). The tool supports resizing to the right (i.e. without moving the beginning of the filesystem) even if the filesystem is mounted. This is what happened.
Yes, it is the correct way.
Note if you want to shrink a partition, you should shrink the filesystem first, only then adjust the partition table. The rule is at any moment the whole filesystem should fit in the partition. Shrinking a mounted filesystem may not be as easy (or possible at all) as expanding it.
Best Answer
This feature is called deduplication. None of the popular Linux filesystems (ext*) support it, but apparently, ZFS supports it partially. There is also a table of filesystems listing, among others, deduplication, but there don’t appear to be any popular choices - it is a planned feature for Btrfs, though.
I would guess that periodically checking your filesystem and creating appropriate hard links is the best you can do at the moment, although that does not imply copy-on-write.