server:
Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-65-generic x86_64)

DB (separate host):
PostgreSQL 11.3 (Ubuntu 11.3-1.pgdg16.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609, 64-bit

Hello Dave!
Actually it does not treat those errors as the same - "No Such Object available on this agent at this OID" error will make an item or LLD rule unsupported, but the rest of the items will work normally.
An actual timeout on the other hand disabled monitoring all items on this host for a while.
What is the timeout setting in your configuration file?
Please repeat the command like this:

time snmpwalk -v2c -cxxxx 172.18.1.4 1.3.6.1.2.1.14.10.1.1

Execute it multiple times.

1. 1. 1. Option: Timeout
2. Specifies how long we wait for agent, SNMP device or external check (in seconds).
   #
3. Mandatory: no
4. Range: 1-30
5. Default:
6. Timeout=3

###Timeout=4
Timeout=20

 
@zabbix.voon:~$ time snmpwalk -v2c -cairwired 172.18.1.4 1.3.6.1.2.1.14.10.1.1
iso.3.6.1.2.1.14.10.1.1 = No Such Object available on this agent at this OID

real 0m0.161s
user 0m0.018s
sys 0m0.038s
@zabbix.voon:~$ time snmpwalk -v2c -cairwired 172.18.1.4 1.3.6.1.2.1.14.10.1.1
iso.3.6.1.2.1.14.10.1.1 = No Such Object available on this agent at this OID

real 0m0.024s
user 0m0.004s
sys 0m0.011s
@zabbix.voon:~$ time snmpwalk -v2c -cairwired 172.18.1.4 1.3.6.1.2.1.14.10.1.1
iso.3.6.1.2.1.14.10.1.1 = No Such Object available on this agent at this OID

real 0m0.025s
user 0m0.007s
sys 0m0.010s
@zabbix.voon:~$ time snmpwalk -v2c -cairwired 172.18.1.4 1.3.6.1.2.1.14.10.1.1
iso.3.6.1.2.1.14.10.1.1 = No Such Object available on this agent at this OID

real 0m0.029s
user 0m0.013s
sys 0m0.008s
@zabbix.voon:~$ time snmpwalk -v2c -cairwired 172.18.1.4 1.3.6.1.2.1.14.10.1.1
iso.3.6.1.2.1.14.10.1.1 = No Such Object available on this agent at this OID

real 0m0.025s
user 0m0.005s
sys 0m0.013s
@zabbix.voon:~$ time snmpwalk -v2c -cairwired 172.18.1.4 1.3.6.1.2.1.14.10.1.1
iso.3.6.1.2.1.14.10.1.1 = No Such Object available on this agent at this OID

real 0m0.026s
user 0m0.005s
sys 0m0.014s
@zabbix.voon:~$ time snmpwalk -v2c -cairwired 172.18.1.4 1.3.6.1.2.1.14.10.1.1
iso.3.6.1.2.1.14.10.1.1 = No Such Object available on this agent at this OID

real 0m0.024s
user 0m0.008s
sys 0m0.009s
@zabbix.voon:~$ time snmpwalk -v2c -cairwired 172.18.1.4 1.3.6.1.2.1.14.10.1.1
iso.3.6.1.2.1.14.10.1.1 = No Such Object available on this agent at this OID

real 0m0.026s
user 0m0.007s
sys 0m0.012s
@zabbix.voon:~$ time snmpwalk -v2c -cairwired 172.18.1.4 1.3.6.1.2.1.14.10.1.1
iso.3.6.1.2.1.14.10.1.1 = No Such Object available on this agent at this OID

real 0m0.025s
user 0m0.005s
sys 0m0.013s
@zabbix.voon:~$ time snmpwalk -v2c -cairwired 172.18.1.4 1.3.6.1.2.1.14.10.1.1
iso.3.6.1.2.1.14.10.1.1 = No Such Object available on this agent at this OID

real 0m0.025s
user 0m0.009s
sys 0m0.008s
@zabbix.voon:~$ time snmpwalk -v2c -cairwired 172.18.1.4 1.3.6.1.2.1.14.10.1.1
iso.3.6.1.2.1.14.10.1.1 = No Such Object available on this agent at this OID

real 0m0.026s
user 0m0.001s
sys 0m0.017s
@zabbix.voon:~$ time snmpwalk -v2c -cairwired 172.18.1.4 1.3.6.1.2.1.14.10.1.1
iso.3.6.1.2.1.14.10.1.1 = No Such Object available on this agent at this OID

real 0m0.032s
user 0m0.016s
sys 0m0.008s

Upon further investigation, when we upgraded from Zabbix 4.x to 5.x, Zabbix created additional SNMP interfaces on most of our hosts (I presume due to differences in the way SNMP items were defined in various templates that we use).

It appears as a result of this conversion the discovery rules got attached to the wrong SNMP interface.

We have (had) a template that triggers alerts on SNMP responding to either public or private communities, while all of our normal SNMP items use {$SNMP_COMMUNITY}.

After conversion, our hosts ended up with 3 SNMP interfaces (with the 3 different communities), and (looking in the database tables) the discovery items are associated with the "private" interface instead of the "{$SNMP_COMMUNITY}" interface, even though the pre 5.x version of the discovery rule specified "{$SNMP_COMMUNITY}" (as shown here: 3 Discovery of SNMP OIDs [Zabbix Documentation 4.0])

So apparently the problem is (or was?) in the schema conversion process while upgrading, or so it appears now.

zabbix=# select distinct it.itemid,it.key_,it.interfaceid from items as it where it.hostid=11760 order by interfaceid;
 itemid  |                                key_                                | interfaceid
---------+--------------------------------------------------------------------+-------------
...
 1161436 | ospfAreaId                                                         |        3002
 1161437 | ospfNbrIpAddr                                                      |        3002
...
  269206 | cbgpPeer2AdminStatus[{#CBGPPEER2REMOTEADDR}]                       |       10985
  269208 | ifInErrors[{#IFINDEX}]                                             |       10985
  269209 | ifOperStatus[{#IFINDEX}]                                           |       10985
...

zabbix=# select * from interface as it join interface_snmp as its on its.interfaceid=it.interfaceid where it.interfaceid in (10985,3002);
 interfaceid | hostid | main | type | useip |     ip     | dns | port | interfaceid | version | bulk |     community     | securityname | securitylevel | authpassphrase | privpassphrase | authprotocol | privprotocol | contextname
-------------+--------+------+------+-------+------------+-----+------+-------------+---------+------+-------------------+--------------+---------------+----------------+----------------+--------------+--------------+-------------
        3002 |  11760 |    1 |    2 |     1 | 172.18.2.5 |     | 161  |        3002 |       2 |    0 | private           |              |             0 |                |                |            0 |            0 |
       10985 |  11760 |    0 |    2 |     1 | 172.18.2.5 |     | 161  |       10985 |       2 |    0 | {$SNMP_COMMUNITY} |              |             0 |                |                |            0 |            0 |
(2 rows)