True, but I'd guess storing an expiry date still takes less space than a license key, so probably not much difference. Just need to allocate enough fixed locations for the number of envisaged future options, as opposed to the maximum number of keys installable at one time.
For one or two licenses perhaps storing a flag+date would be more compact, but once you need space for several licenses then storing just the key (which is fairly compact and applies to all licenses) ought to be smaller.
The other possible issue I can think of with your suggested scheme is that it means that the scope firmware necessarily contains the ability to write to the secure storage area, which would provide an additional attack surface for a hack attempt. You can either use an exploit in the firmware to flip a flag, or use the knowledge of how the secure-store is written to in order to write it directly.
With their existing scheme, the software only needs to be able to verify a hash using the securely stored key value, and never needs to write anything, so the mechanism to do so can be left out entirely. The full key information required to author the hash in the first place doesn't even need to be present at all.
Until some muppet leaves the scope initialisation tool in the firmware package.
Of course as you said earlier, the firmware itself could be an easier target than the licenses, for the scopes where the key information is unknown. If the only license check is in the software, it could be as simple as changing a branch or two. The only thing to work out would be what verification of the firmware code is done, and how to defeat it. But fiddling with that seems far more likely to lead to a possibly bricked scope, so it's not something I'd necessarily try unless I either had money to burn or a really pressing need for a feature I couldn't afford to buy...