The "logic" is that "lite" clients want to save on bandwidth and resources, so they only bother with "configured" items.
This overlays the UX desire to only show what is important.

Most understand the concept of an accessory items state being
- on
- off
However some do not appreciate the nuance of states like
- unknown
- undefined.

The CS2 does not outwardly provide a "undefined" state and, as such, fall back on using the "Standard" to infer the item is undefined, is a common option. I certainly would not call it bizarre.

I am unfamiliar with using the Mobile Station App , however other Apps just do not show "standard" items at all.
In most cases this is shown in a list or group (not in a keyboard form) so "short listing" is good.

In summary:
The real issue is not so much that the app is filtering out "standard" items to mean undefined, but that it is failing to indicate this to the user somehow (usually with a greyed out/ non active view on the button).
So, if what you are describing is still evident , the programmer has probably been fired (or promoted) and any replacement is probably unaware of the issue.

Under the covers there is an exacerbating factor of protocol. At first glance you might think that you can just send a command like ...
- set turnout #456 to branch (energise)
- set turnout #456 to branch (de-energise)
But unfortunately the command address needs to be conscious of the protocol so is actually needing to send
- set turnout ,protocol DCC, #456 to branch (energise)
- set turnout ,protocol DCC,#456 to branch (de-energise)

what this means is that the client(App) needs to ...
- (usually at startup/refresh) read each possible item AND STORE information like the protocol.
- then, for each command - do a lookup of the protocol - before sending the modified command out.

If you imagine that the state for protocol requires 1 byte, then catering for 2048 accessory addresses means
- reserving 2k (2048 bytes) of memory
- spend time accessing that information for each read.
Yes I appreciate we only need a Bit (e.g. 0=MM, 1=DCC) and this may be further compressed if it is store statically, but in ,dynamic real time, operation a decision has to be made as to whether, for each read you want to add 3 or 4 command (processor) cycles to decode a bit from a byte or read it in a single Get at the expense of possibly more memory usage.
AND THEN, it become useful to NOT cater for 2048 items every time.

Comment,
Just to emphasize the protocol point, The backend of the CS2 (GFP/TFP) is absolutely happy for you to have BOTH
- Turnout address #1 MM
AND
- Turnout address #1 DCC
because it treats them as differently - EVEN IF THE CS FRONTEND (Screen) does not. Using a PC program you are quite able to leverage this to address 2368 accessories if you have that many

P.S. you already know the same consideration already exists for Locos with MM, DCC, mfx, SX. In this case the UX does allow you to have both DCC #73 and a MM#73 and a mFX(SID)#73 ...