If Arch's filesystem layout only places grubx64.efi (and possibly the GRUB2 configuration file) to the EFI partition, 100 MB is fine.
But if your layout mounts the EFI partition as /boot (rather than /boot/efi) or otherwise causes the entire kernel + initramfs files to be placed in there, you might run out of space with more than just one or two kernel versions installed. That is going to make kernel updates unnecessarily risky.
You'll always want to have at least two kernels installed: the one you're currently using, and the previous one as a known good back-up. When you are installing a new kernel, that means you'll end up temporarily with three kernels installed: the old, the current and the new one.
If you are brave, you can always delete the old kernel (+ its initramfs file) just before installing a new kernel, but in a production system I would not like to do that.
(Disclaimer: on my main home system, I used to have precisely such a layout before I replaced the system disk with a bigger one.)
Note that the EFI system partition is often formatted as FAT32, and that filesystem type has a minimum number of blocks requirement. If your disk uses classic 512-byte blocks, 100 MB works out fine. But if you later migrate your system to a new disk that happens to use the new 4096-byte blocks, the minimum size of a FAT32 filesystem works out to a little less than 260 MB. As a result, 260 MB is a good forward-compatible minimum size for the EFI system partition for new installations. 100 MB can be a bit too small if you dual-boot.
(Windows 10 uses that size too if it detects the disk is using 4096-byte blocks.)
And yes, with a tool like gparted you could resize or move the following partitions further on the disk, and then resize the EFI system partition. Such an operation would be best done by booting the system from an external media, such as some Linux Live DVD/USB, so that the filesystems you'll need to move won't be mounted and in use at the time.
