I'll give you a Chef example of why DSL is not going to get you far.
Let's say you are running a LAMP stack. Let's say your engineers are good enough to implement a Service Oriented Architecture. SOA means your infrastructure needs to be capable of running a variety of disjoint components. As a DevOps Engineer you need to be able to automate infrastructure and deployment to support rapid releases of application services.
From the infrastructure perspective, application services needs are similar. An application service will probably require a set of Hosts/VMs with specific roles, Vhost configuration, DNS provisioning, Load Balancer config, Logging configuration, User configuration, etc.
If you are writing just in DSL you will end up for a unique Chef recipe for every application service. These recipes are going to be 90% similar, and your Chef repo will become very difficult to maintain because many changes will require edits of multiple recipes (copy-pastes mostly).
Now, if you move beyond Chef's DSL, you will be able to extend Chef's DSL with your own definitions.
My Chef's recipe for a new LAMP application service is php_app "name" do ... that sets up DNS, Vhosts, logging, users and everything required in one command. The code is also very maintainable. To change the way logging is done for all application services, I need to edit only several lines of code in the Chef definition.
DevOps movement started as idea to adapt developer practices in systems administration. One of the principles developers use is DRY (Don't Repeat Yourself). In order to DRY you need to know more than basic Chef DSL.
You are confusing DevOps with full-stack engineering. These are two different things.
DevOps is about continuous deployment, continuous integration, automation, infrastructure as code.
Your choses to do infrastructure as code are Chef (Ruby), Puppet (Ruby), CFEngine (C), and BCFG2 (Python). You will not get very far with DSL-only knowledge of Chef of Puppet only. The case is the same with CFEngine and BCFG2. All infrastructure as code frameworks assume you are going to customize.
As for the resources, the most valuable resource these days is engineering time. Chef specifically and Ruby toolchain overall are hyper-efficient when it comes to engineering time.
The article is very biased opinion indeed.
PHP, JavaScript, SQL, Java and Perl? Wow. Party like it's 1999.
Honestly, I don't see DevOps doing JavaScript. I am no aware of any DevOps tools based on JavaScript and server-side JavaScript movement is only beginning. PHP, Perl, SQL, Java are a dead waste of time.
Major DevOps tools such as Chef, Capistrano, Fog, Puppet, are based on Ruby. Systems are written in C and system control utilities are all Shell.
A DevOps guy needs to know Ruby or Python (pick one), Shell and C. Erlang and JavaScript would probably be next on the list.