The pointer entry in the locals is always the marker of the container of interesting things, you have to disclose it to see the actual contents. If the data type has some useful one line summary (e.g. the string value of an NSString *) then we show that, but if it doesn't, there isn't anything else useful to put there, so I'm not sure it does any harm to show the pointer value. It allows you to view the memory of the object, etc. So it is useful.
I guess your main point, however, is that when you disclose the container, you only see the ivars and you don't see the computed properties.
We don't as a rule show computed properties for any languages in the variables view in lldb. The reason is that to do that, for every stop the debugger has to make a function call into the debugee per property to fetch the values. That's fragile. For instance if a getter has side-effects (e.g. first time it's called it makes some backing object), then just stopping in the debugger can change the execution flow of your program which is not desirable. And if the getter does something complex like fetch data from a server, then that doesn't work at all well. The latter case requires some "don't present this property in the debugger" annotation, but then you have to know to apply that, and again it makes the whole experience more fragile.
It also slows down display of variable values considerably.
There's been a lot of discussion about this choice (which started with ObjC, BTW) over the years. I certainly see the desirability of showing computed properties. OTOH, I've been told both "other debuggers do this and it causes no problems" and "other debuggers do this and I have to turn it off because it causes lots of problems..." So while it would be definitely be interesting to experiment with adding computed properties to the variables display, it's not something to undertake lightly.
And if there's a property of an object that you really need to see, you can add it as an expression to the locals view. So there is a way to do this on-demand.
On the swift side, pure bridged Objc Objects only have computed properties. Given that we don't show computed properties, the most interesting thing to show for pure bridged ObjC objects is the ObjC side of the value.