Building everything from source "by hand" quickly runs into scaling problems, and admins start to roll their own "package databases" in order to cope. Fully-baked package management becomes the solution. The problem here is that distro packages are not the latest development snapshots (for good reasons, most often and presumably). Still, there are times where newer-than-distro-repo software is required.
The author's Pandoc case may be one of those, but I doubt it. RHEL (and CentOS) packages should never (by definition) include showstopper bugs. It's more likely that bugfixes have been backported to the older, stable version. Still, it's possible that the author is correct, and the official package does not meet requirements or is otherwise unusable.
In that case, the best path forward is to build or reuse an updated package, rather than installing from development sources "by hand", e.g. `make install`. It's likely that someone else has already had this problem and has built an updated package, which you could then install, but let's assume not.
Now we're into the wonderful world of package building. We can avoid some of the author's pain here, but mostly there is a tradeoff for having to learn and deal with the packaging pipeline. The upshot is that package building may be scripted and synched with development sources, and you are keeping the metadata inside the packaging system where it belongs and can be managed (think: future updates).