What is the use case here?

A simple switch I can experiment on.

Does it work if you configure it using nmcli commands?

I used nmcli to create a new bridge br2 and to make the enp2s0 interface a member of it then connected enp2s0 to a network containing a DHCP service.
I manually removed the reference to bridge br0 from ifcfg-enp2s0.
Finally I checked that br2 and enp2s0 were in the firewall public zone - they were.
I still have the same behaviour: enp2s0 gets an IP address, br2 does not and is down, enp2s0 does not list br2 as its master.
I could try this on a fresh install rather than one that still has my other config settings, but I have little confidence that it will do anything to invest that time.
Nonetheless, if you have some reason to believe that my old configuration could have prevented the nmcli method from working I will do a fresh install.
Incedentally there is nothing of concern listed in the journal, except repeated "Ignition failed: resource not found" messages that do not colerate with my work.

Can you provide the nmcli commands you ran and also an overview of the HW. Is it a number of distinct NICs or an onboard switch?

Hardware is an x86_64 single board computer with 4 distinct Gigabit LAN connectors using 4 Intel 82583V PCIe v1.0a LAN controllers.

Reinstalled F-IOT 32, with interface enp4s0 connected to a network with a DHCP service.
Updated the OS to latest, rebooted then connected via SSH.
No additonal packages installed.

nmcli connection
lists a connection called "Wired Connection" as used by enp4s0

nmcli con add type bridge ifname br0 con-name br0
nmcli con add type bridge-slave ifname enp1s0 master br0
nmcli con add type bridge-slave ifname enp2s0 master br0
nmcli con add type bridge-slave ifname enp3s0 master br0
nmcli con add type bridge-slave ifname enp4s0 master br0
nmcli con down 'Wired Connection'; nmcli con up br0

Old connection was dropped and a new IP address was picked up by the bridge.
Connected to that new IP address via SSh.

Connected a client device to enp1s0.

ip address
shows the following
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
5: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether 0c:e8:4c:68:4e:24 brd ff:ff:ff:ff:ff:ff
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 82:6d:f4:94:5b:cb brd ff:ff:ff:ff:ff:ff
    inet 192.168.248.80/24 brd 192.168.248.255 scope global dynamic noprefixroute br0
       valid_lft 3620sec preferred_lft 3620sec

So things appear correct, but the client cannot get an IP address.
If a static is given to the client it does not communicate with the netwowrk on enp4s0.
In addition, if the device is rebooted the bridge changes are all lost.

what's the contents of /proc/sys/net/ipv4/ip_forward ?

0 before and after nmcli con down 'Wired Connection'; nmcli con up br0

can you try a "sudo echo 1 > /proc/sys/net/ipv4/ip_forward" after bringing up the bridge and see if that makes any difference?

Sorry, it made no difference.

FYI:
I have tried this nmcli approach on the 8 interface device running Fedora Server 32, it worked fine and /proc/sys/net/ipv4/ip_forward always contained 0
On Fedora Server I now have two bridges running at the same time, one (br0) created using the file config method I started with, and one using the nmcli method (br1).
Both bridges get an IP addresss and a client can connect using either interface bridged to one of the two network connected interfaces.
Interfaces enp2s0 and enp9s0 are connected to a LAN.
Output below from 'ip a' on Fedora Server in which you can see enp2s0 and enp3s0 are in br1 with enp8s0 and enp9s0 in br0, in this case the client was connected to enp3s0.
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UP group default qlen 1000
    link/ether 00:90:27:e0:81:16 brd ff:ff:ff:ff:ff:ff
3: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UP group default qlen 1000
    link/ether 00:90:27:e0:81:17 brd ff:ff:ff:ff:ff:ff
4: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:90:27:e0:81:18 brd ff:ff:ff:ff:ff:ff
5: enp5s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:90:27:e0:81:19 brd ff:ff:ff:ff:ff:ff
6: enp6s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:90:27:e0:81:1a brd ff:ff:ff:ff:ff:ff
7: enp7s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:90:27:e0:81:1b brd ff:ff:ff:ff:ff:ff
8: enp8s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel master br0 state DOWN group default qlen 1000
    link/ether 00:90:27:e0:81:1c brd ff:ff:ff:ff:ff:ff
9: enp9s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether 00:90:27:e0:81:1d brd ff:ff:ff:ff:ff:ff
10: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 1a:35:0b:98:5b:e2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.248.77/24 brd 192.168.248.255 scope global dynamic noprefixroute br0
       valid_lft 5604sec preferred_lft 5604sec
    inet6 fe80::1835:bff:fe98:5be2/64 scope link
       valid_lft forever preferred_lft forever
11: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 62:0a:0e:b6:cd:2c brd ff:ff:ff:ff:ff:ff
    inet 192.168.248.81/24 brd 192.168.248.255 scope global dynamic noprefixroute br1
       valid_lft 6842sec preferred_lft 6842sec
    inet6 fe80::eb2a:4e96:59c3:25ea/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Here it is again with the client connected to enp8s0

2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UP group default qlen 1000
    link/ether 00:90:27:e0:81:16 brd ff:ff:ff:ff:ff:ff
3: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel master br1 state DOWN group default qlen 1000
    link/ether 00:90:27:e0:81:17 brd ff:ff:ff:ff:ff:ff
4: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:90:27:e0:81:18 brd ff:ff:ff:ff:ff:ff
5: enp5s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:90:27:e0:81:19 brd ff:ff:ff:ff:ff:ff
6: enp6s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:90:27:e0:81:1a brd ff:ff:ff:ff:ff:ff
7: enp7s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:90:27:e0:81:1b brd ff:ff:ff:ff:ff:ff
8: enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether 00:90:27:e0:81:1c brd ff:ff:ff:ff:ff:ff
9: enp9s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether 00:90:27:e0:81:1d brd ff:ff:ff:ff:ff:ff
10: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 1a:35:0b:98:5b:e2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.248.77/24 brd 192.168.248.255 scope global dynamic noprefixroute br0
       valid_lft 4398sec preferred_lft 4398sec
    inet6 fe80::1835:bff:fe98:5be2/64 scope link
       valid_lft forever preferred_lft forever
11: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 62:0a:0e:b6:cd:2c brd ff:ff:ff:ff:ff:ff
    inet 192.168.248.81/24 brd 192.168.248.255 scope global dynamic noprefixroute br1
       valid_lft 5637sec preferred_lft 5637sec
    inet6 fe80::eb2a:4e96:59c3:25ea/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

I can move the client, which is configured for DHCP, freely between the two bridges with only a small delay in connecting to the network.
Further, the nmcli method configuration also survives reboot.

I have tested this again using slightly different nmcli options.
The bridge works, but reboot disables it.

I used an up-to-date F-IOT 32 on a four interface x86_64 single board computer.
One interface connected to a LAN with a DHCP service.
Another interface connected to a Windows laptop configured to get a DHCP address.

List interfaces:
ip a
Note the names of the interfaces we want to add to the bridge e.g. enp1s0 enp2s0
List the active connections:
nmcli conn show --active
Note the active connection names e.g. Wired Connection
If a connection and/or interface called br0 already exists, pick unused names for the instructions below.
Create the bridge:
nmcli conn add type bridge con-name br0 ifname br0
Add required interfaces to the bridge, in this example enp1s0 enp2s0:
nmcli conn add type ethernet slave-type bridge ifname enp1s0 master br0
nmcli conn add type ethernet slave-type bridge ifname enp2s0 master br0
Bring the bridge up:
nmcli conn up br0
For each active connection paired with an interface added to the bridge, stop the connection:
nmcli conn down 'Wired Connection'
Wait for the bridge to get a DHCP address.

The bridge will work as expected as long as the device is not rebooted.

After reboot the bridge was still listed by "ip a" but without an IP address. Files created by nmcli in /etc/sysconfig/network-scripts/ still existed. The interface connected to the LAN had an IP address. The connection for the interface with a client device was show as "bridge-slave-enp1s0" by "nmcli conn show", but the client device would not get a DHCP address. After a couple of minutes, that connection was listed as "Wired Connection".

To restore the bridge, issue the commands to bring the bridge up and stop the active connections paired with interfaces added to the bridge.

Bridge now seems to work in my test after upgrade to F-IOT 33.20201215.0 on x86_64