I knew some implementations have extension to allow custom
capabilities, but is not portable.

This does not matter.

Interesting enough, the extension is something like adding termcap
entry in the terminfo, and inconsistent with the original idea of
terminfo.
The idea of terminfo(5) (terminfo(4) might be more precise, since
UNIX System V reordered section number) is to use a fixed array of
capabilities to speed-up loading database, so basically there is
no room for custom capabilities.

>
> To use custom capabilities, we can use termcap almost everywhere.
Things have moved on.
Both ncurses and my implementation allow extensions.

Do you have any benefit to use terminfo for programs that are
already written to use termcap?
Since our new termcap library is fast, I don't see any benefit to
rewrite termcap programs for terminfo. It just causes loss of
features such as $TERMCAP.

My terminfo implemenation is faster still as it uses hash tables for
termcap and terminfo lookups. As the termcap design is to do a string
lookup per capability it's always going to be slow. terminfo allows
calling known capabilities directly or by going the string lookup route
like termcap. It's still quite quick thanks to hash tables.

As to re-tooling code in terminfo vs termcap?

Less code for termcap applications for staters, which means smaller
binaries and less memory requirements. Here's a good example of one of
our applications converted to terminfo