Any reason you choose to build on the command line interface of lsof rather than reusing its api by diving into its source code?
Meanwhile kernel ABIs can and do change between versions (the API less so, but it still means that you have to rebuild your code).
What can happen however is that a tool of the same name might have a different output or behavior on different operating systems (most notably between the GNU and BSD variants). But in this case the kernel API is probably different as well, so you'll have to implement an abstraction layer anyway.
By contrast, lsof can change output at any time. I've not done enough parsing of lsof to be familar with past changes, but have seen meaningful changes in the default output of lsblk, df, and other core CLI tools that wrap system information.
Sloth dates back to 2004, at which point parsing lsof's output would definitely have been a more sensible choice than replicating the kmem parsing code. On the other hand, if I were writing something like Sloth today, though, I'd use libproc, because I think it'd be easier overall, and it would also make it more feasible to improve the core functionality (like adding a progress bar or lazy querying).
However, lsof does have a flag (-F) to specify how to format its output, explicitly documented in the man page as being intended for other programs that want to parse its output, implying that it will remain stable. And Sloth uses this flag. Thus, even from a modern perspective, its approach is perfectly reasonable.