SOA record at apex of every zone on the child nameservers is mandatory per DNS specification, see §6.1 of RFC 2181:
The authoritative servers for a zone are enumerated in the NS
records for the origin of the zone, which, along with a Start of
Authority (SOA) record are the mandatory records in every zone.
Such a server is authoritative for all resource records in a zone
that are not in another zone.
A zone not having a SOA is then not DNS-conforming.
Nameservers will reject it at load time:
$ cat example.com
example.com. 1 NS a.example.
example.com. 1 NS b.example.
$ named-checkzone example.com example.com
zone example.com/IN: has 0 SOA records
zone example.com/IN: not loaded due to errors.
Maybe you can find a setup where it works, but why risking it?
Besides being mandatory per specification, there are at least 3 items in the SOA record that are needed by clients (all the other items are mostly useful only to the nameservers administrator if its set of nameservers use AXFR/IXFR/DNS Updates to update themselves):
RNAME is normally the email address of the person responsible for the zone, that you can contact in case of problems; unfortunately nowadays you may not get an answer there or it may not even be a valid existing mailbox anyway, so theoretically useful, in practice not sure
MNAME, per §4.3 of RFC 2616 is needed for DNS Updates:
4.3. If the requestor has reasonable cause to believe that all of a zone's servers will be equally reachable, then it should arrange to try the primary master server (as given by the SOA MNAME field if matched by some NS NSDNAME) first to avoid unnecessary forwarding inside the slave servers. (Note that the primary master will in some cases not be reachable by all requestors, due to firewalls or network partitioning.)
- the SOA
MINIMUM has been redefined over the year to now be the "negative TTL", the amount of time a cache can keep the
NXDOMAIN reply it got (since an
NXDOMAIN reply would return no records in the answer section per definition, there won't be there any TTL to find). See §5 of RFC 2308:
Like normal answers negative answers have a time to live (TTL). As
there is no record in the answer section to which this TTL can be
applied, the TTL must be carried by another method. This is done by
including the SOA record from the zone in the authority section of
the reply. When the authoritative server creates this record its TTL
is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
This TTL decrements in a similar manner to a normal cached answer and
upon reaching zero (0) indicates the cached negative answer MUST NOT
be used again.
Proper caching of
NXDOMAIN replies is important for performances, as outlined in RFC 8020 "NXDOMAIN: There Really Is Nothing Underneath": if a name triggers an
NXDOMAIN reply then the recursive nameserver can, during the time the entry is cached, reply immediately for all names "below" the one queried, as it knows that no name can exist below, per the DNS design of having all names in a tree.
Also, multiple registries test the configuration before allowing to do the delegation. It is not the case for UK, but it is the case for DENIC (.DE) for example. See §2.1.4 in https://www.denic.de/fileadmin/public/documentation/DENIC-23p_EN.pdf that outlines the test on SOA.
Various tools check for it also. See Zonemaster at https://zonemaster.net/ and the explanation of its test on SOA at https://github.com/zonemaster/zonemaster/blob/master/docs/specifications/tests/Delegation-TP/delegation06.md