Sure, I was simply noting something you can do now. Unless you’ve very long $Name values (something I’ve leaned, out of enlightened sef-interest, is generally not useful for a host of display reasons) then simple ensure the columns used are wide enough - you may be unaware displayed column widths are not fixed; the default width is generally too narrow for textual values.
I’m not sure that, in principle, putting extra info, e.g. subtitle, up onto the outline as a secondary row, is any less of a resource drag than using a column. Of course it boils down to the implementation and the ROI of optimising the view performance for a not default option. In context, heavy column view use likely could be optimised for but likely at the cost of something else. Thus I’ve learned to toggle columns off when not using them at the present moment. A tab remembers the ‘current’ column settings whether displayed or not. Plus, indications are that consideration is being given to make such customisations storable in the future - essentially storing such config data that can then be applied to any tab.
Not that it matters particularly, but the OmniOutliner behaviour is slightly mis-described above. I only know this from assisting a user with so OmniOutliner/Tinderbox interchange work. OmniOutliner has no notion of things like Tinderbox’s $Text or $Subtitle. Rather if you add additional paragraphs to the item’s title, the second paragraph appears in slightly smaller text, as if it were a subtitle. IOW OmniOutliner’s column #1 is—in Tinderbox terms—$Name/$Subtitle/$Text all in one. We can of course make other additional columns in OmniOutliner, in which case these function akin to Tinderbox user attributes