Yes, that is normal. The option is removed for devices that have no hw-offload, the version before erroneously added that option even when it was not active.
Okeeeee 
Is there a list where this option is available ?
br Richard
Edit: found
It's in the changelog:
If your hardware has no L3HW Fasttrack support, then the parameter is no longer there. Here are the list of devices (highend CCR and CRS with Prestera 98DX8xxx / 98DX4xxx switch chips):
L3 Hardware Offloading | RouterOS Manual
If you have those devices, then if the setting is "on", you also won't see it in the export because the default value is now "on".
Adding my RB3100 and RB1100AHx4 to the successful upgrades list.
I have all the most popular gear.
RB4011 wifi variant upgraded from 7.21.4
WAN connectivity dropped even after routerboard fw upgrade restart; after few mins seems stable for now; need to monitor.
Sidenote:
Shameless plug; would appreciate any help:
Successful upgrades from 7.21.4 long-term to 7.21.5 long-term on the following platforms:
- RBM11G (product code RBM11G)
- LDF LTE6kit (product code RBLDFR&R11e-LTE6)
- mAP lite (product code RBmAPL-2nD)
- still pending updates on RB1100AHx4 (product code RB1100x4) - to be scheduled
CCR1009-7G-1C-1S+, multiple RB1100x4, RB5009 and RB450Gx4 - all survived.
I updated my CCR2004-1G-2XS-PCIe (not in a PC, used as standalone device powered directly to the PCI connector by using a riser card to provide power)
Update went fine, but my provider disabled the 10GBit/s fiber link as he was claiming that "Storm Control" kicked in. The provider tells me that this usually means something like Broadcast/Multicast storms, layer 2 loop, etc. My configuration is unchanged since months, except for the upgrade from 7.21.4 LTS to 7.21.5 LTS.
Questions:
- Could this possible be related to any of the updates in 7.21.5 LTS?
- How big is the (security) risk to downgrade to 7.21.4 (I am not using PPP at all)?
Thanks in advance for any insight 
PPP is L2 protocol not used directly but instead by other protocols like SSTP, PPPOE etc.
I would say that if you are not running any VPN servers and do not allow any access from internet you should not be affected, on the other hand you could try the downgrade if nothing else to confirm that it really is this release issue...
I just saw this in the release notes:
*) route - removed deprecated "/routing/route/rule" menu;
In case there are such rules present (which is my case on some routers), are they being converted or moved somewhere else automagically or do I have to change and adapt the config myself prior to upgrade?
Thanks @bratislav for the insights I am not running any VPN servers or SSTP/PPPoE on that device, just DHCP clients (IPv4 and IPv6), so I consider mysalf "safe for a downgrade".
Interresting you mentioning "Layer 2 protocol" as my provider mentioned L2 loops as a possible cause. I will stay on 7.21.5 for now, but when it occures again, I will downgrade and post here again.
They are talking about Ethernet Data Link Layer which is also Layer2, that has nothing to do with PPP
All rules will still be there after the upgrade. It’s just the old menu path that’s being removed and replaced by /routing rule. If you use the old path in scripts, you’ll need to update them, and old exports won’t work anymore.
In typical MikroTik fashion, this makes it harder to upgrade CPEs in volume because of these breaking changes. Hopefully that ends with long-term 7.21.5.
ltAp, wAPax, RB5009 --> OK !
cAPax: OK, but there is a global variable called "defconfMode" ?
br, RIchard
Thanks for your reply! No, I don't use them in scripts, only for Policy-based routing combined with action= lookup to force specific traffic to always use a specific routing table and a specific WAN link. So that should still work after the upgrade according to what you say...
Yes, I noticed this change and was worried like you, but really the only issue is that before there were 2 commands that did exactly the same: /routing/rule and /routing/route/rule. Now the second one has been removed but the first one remains working as before.
confirmed, rules are still there, as you said. 
Upgraded an RB4011 (CAPSMAN), 2 hap ax2-s, 1 wap ac and 1 hap ac2 (these ones are all CAP-s) - for some reason wifi on the hap ac2 stopped working. I tried provisioning it again, even reset configuration to CAPS mode but still no luck. I don't see anything in the changelog impacting CAPSMAN functionality, anyone else experienced this?
EDIT: Found the culprit, wifi-qcom-ac was disabled and I cannot re-enable it.
EDIT2: Had to reinstall wifi-qcom-ac, now it works. Strange...
hAP ac2 ... how's its disk space? hAP ac2 (and cAP ac) tend to run really tight with disk space and when disk gets full, all kind of random problems appear. Could be that disk got full during upgrade and wifi package did not install. Yes, in principle ROS does check for enough free space before starting upgrade ... but there were reports that it underestimated necessary space before. We used to have a rule of thumb not to start ROS upgrade without at least few hundreds of kilobytes of free storage.