-CentOS 7.3 - usage 209.57 MiB, 2 LTS kernels installed
-Manjaro - usage 110.70, 1 kernel installed
-Mint 17.3 - usage 94.73 MiB, 1 LTS kernel installed
-Fedora 25 - usage 200.67 MiB 3 kernels installed
-Fedora 26 - usage 228.77 MiB, 3 kernels installed
-Fedora Rawhide - 204.33MiB, 2 kernels installed
-Solus - 115.49 MiB, 3 LTS kernels
So yes, at a push allowing for new kernels being installed you could get away with a 500 MiB partition still even allowing for a distribution upgrade or a second OS sharing the same /boot. That is if you have the default keep only 3 most recent kernels policy in place.
I think 1 GiB /boot is really a belt and braces approach right now. That is unless RH developers know something we don't about the future of kernels and expect them to balloon in the next decade.
Kernel sizes have grown compared to older LTS kernel branches as indicated above (the exception being CentOS where they are larger anyhow). However, I don't see that kernels have grown enough yet that /boot really needs to be double the old recommended size of 500 MiB.
It would however possily be prudent to keep an eye on the contents of /boot. @nobody experienced an anomoly with a failed kernel cleanup recently. If that happened on a semi-regular basis, then /boot would soon fill up at 500 MiB.
As Ext4 also occupies some space for the inode table, journal etc. running critically short may cause issues in the future but even allowing for that you could allocate 750 MiB for example and have enough wiggle room.