Regardless that I know basically nothing at all about
how to make an UEFI bootable ISO image
I like to suggest a general approach
how to deal with such kind of issues:

Provide a new variable in default.conf like

# The size of the UEFI boot image in KiB.
# It must be big enough for initrd and kernel.
# If unset or empty rear will use default/fallback values:
# Usually 32000 KiB should be sufficient.
# When elilo or shim is used 128000 KiB should be sufficient.
# Additional space is needed when special backup restore software
# is used (e.g. additional 96000 KiB when TSM is used):
EFIBOOT_IMAGE_SIZE_KiB=32000

and use that in the efiboot_img_size function.

Reasoning:

As far as I understand it from #810 (comment)

Work-around, if any
I have modified rear code:
extended UEFI image size by experimentally
determined value for this particular setup

the main problem is how to automatically determine
a correct value.

When there is no reliably working automatism,
I think it should be possible for the user to
explicitly specify something that makes it work
for his particular case - otherwise we may need
to endlessly adapt and enhance the automatism
trying to make it work for all (corner) cases until
it becomes an overcomplicated monster that
nobody can maintain any longer.

A possible enhancement request:

I wonder why the size is measured in KiB and not in MiB.
Is such fine granularity really useful?
All rear defaults have '000' at the end i.e. are measured in 1000 KiB
so that I assume using 1024*1024 Bytes as unit is more appropriate.

By the way:

I needed reverse engineering to find out that the measurement unit
of that plain "size" named variable is KiB because I found it used in
20_mount_efibootimg.sh

dd if=/dev/zero of=$TMP_DIR/efiboot.img count=$(efiboot_img_size) bs=1024

I wished variable names were more meaningful, cf.
https://github.com/rear/rear/wiki/Coding-Style

Thanks for feedback!

Frankly, I am against adding new variable to the config file (there is too many of them already), as we can find the needed value automatically (by counting the total size of the to-be-copied files). ReaR user should not be forced to determine the space needed for uefi boot image I think.
Perhaps @gozora may comment on this, as this has been discussed when he was adding his ebiso support patch.

I absolutely agree with the variable names and units comment. Also [[ ... ]] && ... does not seem to honor the style as i read it now :)
I'll change it like:

dd if=/dev/zero of=$TMP_DIR/efiboot.img count=$(efiboot_img_size_MiB) bs=1048576

At the time I was writing ebiso, I primary focused to implement it into ReaR with least pain possible.
So I just took existing approach for ISO creation and just extended it, with a thought that it (if there is need) will be changed. Looks like the time is here.
As far as I remember dd ... command was called (with some fixed size) to create blank UEFI image and consecutively mounted. After loop mount was settled, files were copied.
In this I agree with @pavoldomin that users should not decide about image size, but size should be rather determined automatically before dd command is triggered. Maybe we could add some additional script/flow.before blank image is created to have some better guess about final image size?
It is been a time since I was in touch with ReaR code, so I definitely need some refreshment.to have more accurate view.
@jsmeix if you want, I can take a closer look (during weekend) to find possible way, how to automatize this.

@pavoldomin
I fully agree with you.

My above comment was made under the (wrong) assumption that "there is no reliably working automatism".

When rear "can find the needed value automatically (by counting the total size of the to-be-copied files)" it should do that and not bother the user with tasks that can be reliably automated.

@gozora
I would very much appreciate it if you could have a closer look.

I am not really the right one for this issue because
"I know basically nothing at all about how to make
an UEFI bootable ISO image".

As mentioned in issue #810, pull request #813 was created and it should supersede this pull, request.
Hope nobody minds ...