treatAsInternal is meant to lean on an understanding of access levels and how they affect documentation. An internal symbol is not usable from outside the package; therefore, @_documentation(treatAsInternal) would apply that logic to that symbol but only for documentation. @_documentation(...) in general messes with the visibility of symbols, so the juxtaposition of alwaysVisible and treatAsInternal shouldn't be that jarring since they're meant to be taken in the greater context of visibility and documentation in general.
I don't think relying on an understanding of access control keywords, at least the difference between public and internal, is that much of a stretch. The use of internal is meant to be a familiar metaphor for package and documentation authors. Your proposed names introduce a new concept of "audience", i.e. "who is the audience of this API", whereas we already have that mechanism in place for "public" versus "internal" docs, which again echo the access control keywords.