If we are to talk about types, I'd hope people would look at languages like Haskell or Standard ML—or maybe even ATS, Agda, or Coq—for future direction, not Lisp.
Unlike Lisp, C++ lets one write efficient, generic algorithms that can operate on several types of data. Lisp cannot, and falls back to dynamic type testing, which makes for slower code[1]. Basically your only option in Lisp is to specialize everything manually, or inline everything. Both approaches are extremely poor. As I hinted, Haskell and Standard ML do an even better job than both C++ or Lisp. This is talked about a good bit in this article [2].
(Also, for the record, Lisp has no concept of information hiding, interfaces, or APIs. And no, Lisp's packages are just convenient structures for grouping somehow related symbols together.)
The article talked about declaring function types in Lisp. Many implementations plainly ignore those and they provide no value. It doesn't help that idiomatic Lisp code usually doesn't include such declarations.
Lastly, a lot of the things in this article were SBCL specific, and had little to do with the Lisp language itself.
Like others have said, I don't think any points demonstrate that C++ is converging to Lisp. And if it were, that's probably a bad direction anyway, given the author's initial statements about heading toward an algorithmic language.
[1] No implementation of Lisp has true, flexible compile-time polymorphism or any type-algebraic structure; all inferred types must be concretely realized during the inference.