I believe the code presented would have benefited from a lambda-based API approach instead of an object-oriented one. In Javascript:

  // global, since the cached values were apparently global in the original
  let cache = {};
  let lastCachedTime = 0;

  // Utility for fetching potentially cached values, or computing them 
  // if there's no valid cache entry.
  let cached = (id, recompute) => {
    // I don't love this policy, but thankfully it's all in one place.  
    if (lastCachedTime <= lastMidnight() || lastCachedTime <= lastNoon() {
      cache = {};
      lastCachedTime = Time.now();
    }
    if (!(id in cache)) {
      cache[id] = recompute();
    }
    return cache[id];
  };

  // now we get to have a nicely factored, simple, conceptually independent, 
  // declarative code for the dashboard.
  function displayDashboard() {
    print("Total Users: " + cached("numContent", => countUsers());
    print("Articles written: " + cached("numArticles", => countArticles());
    print("Words written: " + cached("numWords", => countWords());
  }

This achieves the same "Embedded Design" goal. If you squint, it's actually virtually the same as the DashboardStatComputation/DashboardStat/Dashboard the author comes up with, where each lambda in the displayDashboard function is corresponds to a DashboardStatComputation.

I prefer this lambda-based design because it reifies the "form" into a single, callable, function: cached(). If you want to use the idea of cached(), you don't have to subclass anything or know about its implementation details— just call it.

(PS. the code's even nicer in CoffeeScript)