Portability is only a partial issue. SWI-Prolog reflection API and native tools are oblivious of Logtalk language constructs and thus of limited usefulness for Logtalk developer tools. The only notable usage exception is the diagrams tool but there the SWI-Prolog reflection API is only used when generating diagrams for Prolog module applications.
Logtalk objects, protocols, and categories are not an abstraction over Prolog modules. Message sending is not an abstraction over module-qualified calls. Not to mention the Logtalk predicate semantics that don’t exist in Prolog. Thus, trying to reconstruct the related contextual information from the generated intermediate code, either for the linter or for Logtalk own reflection API, would be too much work for little to no gain.