For standard Unix tools? Not really, since they're often used in scripts and everything breaks if the formatting changes. Generally any new feature is hidden behind new flags on the command line to avoid breaking anything. There are exceptions of course but I doubt the output of lsof will change any time soon.
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.
In this case, `lsof` is a relatively lightweight parser for /proc. The /proc filesystem API is amazingly stable. The unstable ABI is internal to the kernel itself; the interaction with userspace is where backwards compat is held as the highest guiding principle (see Linus's remarks about breaking userspace).
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.
If anyone's curious: Traditionally, lsof on BSD would just open /dev/kmem and read the info directly out of the kernel's data structures! It still does that on FreeBSD, and used to do it on macOS prior to 2006, when Apple added the more sensible (and stable) libproc.h API in one of the Tiger software updates.
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.
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.