Many of the comments here appear to have been made without reading the full post. Maybe because I'm not a Vim user it made sense to read the post in its entiret

Many of the comments here appear to have been made without reading the full post. Maybe because I'm not a Vim user it made sense to read the post in its entirety. From the post: "Attempts have been made to implement functionality with built-in script languages such as Python, Perl, Lua, Tcl and Ruby. This never gained much foothold, for various reasons. Instead of using script language support in Vim: Encourage implementing external tools in any language and communicate with them. The job and channel support already makes this possible. Really any language can be used, also Java and Go, which are not available built-in. Phase out the built-in language interfaces, make maintenance a bit easier and executables easier to build. They will be kept for backwards compatibility, no new features. Improve the Vim script language, so that it can be used when an external tool is undesired. All together this creates a clear situation: Vim with the +eval feature will be sufficient for most plugins, while some plugins require installing a tool that can be written in any language. No confusion about having Vim but the plugin not working because some specific language is missing. This is a good long term goal." So, as I read this, his argument is that it makes sense to offer both external language support and Vimscript.