Most languages that I've worked with (Python, JS, Java, C#) have a fairly robust set of command line tools for basic developer tasks. In all of these, I can build/compile from the command line. Being CLI-based, all of these things are scriptable as part of an automated build and testing process.
Compiler
In OpenEdge, there is no official command line compiler. Compilation must be done from GUI tools (not scriptable) or by running an OpenEdge procedure that uses the compile command. As such, we have a set of custom shell scripts to run a custom-written compile procedure file. For newer development, we are using pct, but that is a set of 3rd party tools for Apache Ant, a Java-based build tool. What I'd really like to see here is for Progress to officially endorse PCT and to contribute to it themselves. Ideally, they would ship it with OpenEdge. They do seem to be pushing Ant as an automation tool, so that would fit.
Test Runner
It's a similar story for their test environment. ABLUnit is included with OpenEdge and you can run it from the IDE, but there is no way to run it from the command line. Pct provides a task for running your ABLUnit tests, so if that were included as I suggested above, that would be an acceptable solution.
Linting
For linting, the story is a bit worse. I suspect, based on talking with other developers, that the OpenEdge community doesn't value linting tools as much as I do, but if you are doing code reviews, they are invaluable for saving time and maintaining code quality. There are currently 2 community-driven approaches to linting that exist: ProLint and the OpenEdge Plugin for SonarQube.
ProLint seems like exactly the sort of tool that I would want, but it's maintained by one person (who, for a while was not updating it) and is difficult to contribute to. It relies on a library called Proparse (written by the same developer). Proparse is written using a Java tool called ANTLR, which uses a grammar file to output a java-based parser. Then a tool called IKVM is used to convert that into a .Net DLL for use in OpenEdge-based products. So, in order to contribute to ProLint, one must know some Java, .Net, OpenEdge, as well as having knowledge about grammars and parsers.
The SonarQube Plugin also relies on Proparse, so has some of the same problems as ProLint. It also requires users to deploy and maintain a SonarQube server, which means a beefy server (Java + Database) and knowledge of deploying and maintaining Java apps. It's a really heavy approach for linting, IMO, esp. for smaller teams.
Ultimately, I'd like to see Progress release their parser for use by the community. Open-sourcing it would be a great step, but even if they don't do that, at least they are using it internally, so it should stay updated with OpenEdge releases. Then we could write our own linters and code analysers on top of it.
Mock/Stubbing Library
In a similar vein to the above, while it is possible to write out your own stubs if you do your architecture right, I'd love to see a mocking or stubbing library to make unit testing require less manual code creation. It would go a long way to helping encourage developers on the fence about writing tests to get in the habit.