This might be faster if the device is large. It should be enough to wipe out the partition table and let you start new.

And taking a full backup before you start would give you a bit less to worry about.

I just want to wipe everything, and start fresh.

Then, you can use dd, but you will have to be extremely cautious to not wipe out the wrong unit.
To use dd you have to write as root

dd if=/dev/zero of=/dev/YOUR-RAW-DEVICE

For instance:

dd if=/dev/zero of=/dev/sde

Please note that there are not a number in the name of the unit. This is important.
Double check your typing before ENTER!!
Wait to completion and then use sync before unplugging the stick.

Also, what are you trying to do ? Are you trying to wipe off everything on the media and start fresh ? Or are you trying to write something on one of the partitions, while leaving others intact ?

I guess it's not easy for a graphical tool developer team to present and manage that kind of partition overlap which barely is understandable for normal people.

But there is also a flaw in GDU, one that would be super easy to fix really. As all that's needed is for it to call wipefs on the empty space before creating a new partition.

# Proactively wipe ISO-9660 signatures to prevent Gparted detection issues
wipefs -a -t iso9660 "$USB_DEV" 2>/dev/null || {
    error_dialog "Failed to wipe ISO-9660 signatures on $USB_DEV."
}

It's literally that easy. But GDU doesn't do it, and it leaves 5 bytes that confound gparted. So i'm sticking by what I said, they both need to be fixed.

It's not a "flaw" in parted, iso9660 on anything

It absolutely, objectively is a flaw when partitioning tools don't check the actual, contractual structure of a partition table including the 0x55AA signature, because they "think" they found an ISO9660 filesystem based on loosey-goosey pattern matching of non-contractual parts of the MBR. Everything in the MBR before the partition table and the two-byte signature is not and must not be used to conclusively determine disk structure. Any tool that does is doing it wrong.

Edited to add:

It's still baffling that gParted and parted behave differently, when they are supposed to be using the same underlying libparted library. As convenient as the GUI is, it's only gParted that gets it wrong, while parted (and presumably libparted) work correctly.

All this will confuse traditional partitioning tools, especially if the device was previously partitioned and whatever you used to write the image didn't remove the existing partition table (and backup), RAID headers, or whatever else was on there.
It's not a "flaw" in parted, iso9660 on anything but optical media was just never supposed to be a thing and the spec for what should be at the start of the disk is intentionally vague.

Ed. Also, this.

Having a bootable iso image and other filesystems on one device simultaneously is even more of a hack, and generally requires installing a (second) bootloader that can chainload an iso9660 [insert system-specific hackery here] boot record or handle loop-mounting the filesystem and locating the kernel image itself... This is why grub-imageboot and ventoy exist, and it's also why they are so complicated and unreliable.

On the OP: Make sure the device is properly clean, first with a (fast) tool like wipefs, and if that doesn't do it, nuke the entire device with a (slow) cp or dd from /dev/zero. Check the latter can write the entire expected size of the device - if it can't then what you have is likely a hardware problem.
As for "takes ~2s", you're probably just seeing write-cache. Try oflag=direct to bypass kernel caches (see dd manpage).

Given you're creating a boot stick from some image with dd of=/dev/sdb if=./cool-devuan  your stick becomes a kind of CD or DVD: there is only one partition with the size of the image! On the other hand gparted /dev/sdb shows you the whole space on the device just because the found partition table is interpreted a similar way like grub will do.

There is no supposed "flaw" in gparted: GÜ has spent his last raw DVD to chimaera and has checked that DVD with several machines successfully. GÜ has copied that 1.9GB image to a 32 GB USB-Stick (your devices may differ)

dd if=./cool-devuan of=/dev/sdc

The BIOS/UEFI recognizes the Stickas  a "bootable CD" and boots successfully, BUT gparted /dev/sdc shows roughly 30GB unused spaced on the stick. And that is good! Doing a dd of=/dev/sdbc1 if=./cool-devuan and creating a filesystem on /dev/sdc2 while keeping the stick bootable is left as an exercise to the reader.

The gnome-disk-utility should "see" your other partitions correctly, but even if you make new ones with it Gparted still won't "see" them even if GDU and your file-manager do, because GDU doesn't pre-emptively wipe either. But it will see extra partitions even if Gparted won't.

Both gnome-related, so good luck with getting them to admit it's an issue or fix it.