1. PETSc
One of the PETSc developers have developed some FindPETSc scripts. They are not part of the main distribution anywhere yet as far as I know, so we have to include them.

This would replace the old methods, it does multiple scans for libraries etc., and well, if the PETSc developers think this is how it should work I can only assume they have a good reason (I don't know why PETSc just can't make a PETScConfig.cmake file)

This is also to make the cmake build work nicer with module systems typically used on clusters (like Lmod, which I use in my current job as a sys admin at Chalmers).

It also means we are doing less complicated stuff in our scripts, which I consider a very good thing.

2. STD version,
Newer CMake (3.1 and up) supports a very convenient macro;
set (CMAKE_CXX_STANDARD 11)
which takes care of all compilers that CMake is aware if (which certainly is enough for us).
This version also allows to specify specific c++ features, if we needed to pick some individual parts from newer std's.

3. C++14 has at least one thing I would really like to see us use; make_unique, which was overlooked in C++11.
Also return type deduction would be covenient, and constexpr is a bit more useful.
And, [[deprecated]] would be very convenient for locating problematic parts of the code. Code comments only goes so far (i.e. they are almost always neglected/ignored).

I don't think it would be pushing for new features to quickly; getting a hold of a modern compiler shouldn't be all that hard, even for someone stuck on an old LTS.
GCC 5 or up should be fine. In fact, this should be done either way.