There are multiple questions in the post, so let me address these separately:
Scaling: Every parallel program is composed of sequential and parallel tasks, and Amdahl's law then guarantees that there is a limit to how well a program scales. Martin Kronbichler's group (which wrote the linked to step-37) has spent an enormous amount of time finding the sequential parts of the program and reducing the time spent there and/or parallelizing them as well. As a consequence, they can show good scaling up to 300k processes in some cases. But experience shows that every time you go from $N$ to $2N$ processes, you will find another part of the code that now is the bottleneck, and you will need to address that to make a program scale further. Experience also shows that for finite element methods, this can actually be done (and Martin's group is among the best in doing so) and I have no particular reason to believe that they can't also go to 1M processes and more -- but it's going to take a good amount of time and access to some of the largest machines in the world to make that happen.
There are also components of the parallel parts of the program that can be bottlenecks. For example, every finite element code needs to do dot products between vectors (in fact, many!) and that requires a reduction operation where the local parts of the dot product are summed up over all processes. This is done in a tree reduction algorithm which has $\log(P)$ complexity -- and you can actually see that factor if you get access to a machine that is just large enough. There is very little you can do about that if you just use existing algorithms -- which is why people are starting to implement and use communication-hiding Krylov subspace methods and similar.
Speed: At the end of the day, scalability does not matter -- speed does. What is a dog slow code good for that you can scale to large machines, if there is another code that can solve the same problem in 1/10th the time on 1/100th the number of processes? As a consequence, working on speed is also an important area, and there, too, like finding the sequential bottlenecks, more work always needs to be done. This is why people port their stuff from CPUs to GPUs, for example: Not because they hope for better scalability, but because they want faster execution.
Equations: You also ask about whether there are equations where the matrix-free approach of step-37 is not appropriate or simply does not work. At the end, the only equations we know how to solve efficiently are elliptic problems such as the Laplace equations, and ones for which we can devise good preconditioners by solving elliptic equations (e.g., for the Stokes equations). That's because for these we know how to build multigrid methods as preconditioners -- the only known class of optimal preconditioner. But for all other equations that we want to solve implicitly, we are in a decent amount of trouble -- so take your favorite non-standard equation (say, a pattern-forming equation, or the high-frequency case of the Helmholtz equation, or the linearization of some random nonlinear equation) and we no longer know how to build good preconditioners, let alone in a matrix-free way. So there is still a lot of work left in this area regarding making things scale well to large problems.
The only other category of problems where we know we can scale well is for explicit time discretizations of hyperbolic problems -- say for high-speed flow. In those cases, we do not have to solve a linear system in each step (typically the largest component of finite element solvers by run-time), and codes for this kind of problem have also been shown to scale to very large machines. For these kinds of problems, you're back to just finding the sequential bottlenecks of problems. At the same time, if you have been listening to the talks of David Keyes over the past 20 years, you will have heard that these problems can often be solved faster with implicit time stepping methods -- where each time step is vastly slower, but you can take vastly larger time steps. In those cases, you're typically back to the question of how to find efficient and scalable solvers for the linear systems, and that is not always entirely clear: More research is certainly necessary.
Summary: I think we will still have plenty to do regarding scalability and speed of finite element codes. If you ask Martin, at any given time he can probably give you a list of ten places in his code base (including deal.II) that he knows are or will be bottlenecks and that need to be addressed. My perspective is more on the solver side, and I can always give you ten examples of problems for which we currently don't have good solvers and preconditioners. We're not going to run out of things to research for a good long while :-)
