I probably should have framed it clearer in the article. By “defining the seam” I mean all of the work that goes into that design process and doing so with the seam first is in contrast to designing the context internals first. Granted, the entire design process can be done in a number of ways. BDD is probably one of the best, but in theory (not recommended) you could waterfall the spec. :)
With respect to performance, any router will need to follow rules 1 and 2, and all input ought to be validated (rule 3). Additionally, there are type of data (enum-ish values, etc) that may make there way into the database and violate the spec when returned, making rule 4 relevant. In other words all the CPU cycles mandated by the four rules are needed regardless if the spec is being evaluated or not. Skipping that effort to solely to improve performance is firmly in the realm of premature optimization.
Another way to look at it is from the perspective of SLA. If a foundational service has a guaranteed 3 nines SLA of 100ms, but is currently operating at 60–70ms, you have a ton of time to work with. Adding an extra few milliseconds to an already over-performing system will save dozens or hundreds of hours of developer time on reduced maintenance alone. And developers are way more expensive than VMs.