Choosing an aggregate operation which is already implemented in PIG probably confused the message.
One theme of those slides, as @marivas11 pointed out, is that composability of predicates is a powerful alternative to the approach of user-defined functions (UDFs) which are popular in other Hadoop abstractions.
The benefits of composability extend far beyond a relative difference in code volume:
composabilty of predicates reduces "accidental complexity" as defined in Moseley/Marks 2006, which benefits software engineering costs
the concise code which results is also quite close to stated requirements; this follows almost directly from the practice of test-driven development (TDD) since Cascalog subqueries effectively become test statements -- the Cascalog-Midje addition of facts and mocks by Sam Ritchie is quite good
getting rid of UDFs relieves a very troublesome problem on Data teams which must develop complex workflows: crossing a language boundary from Java to Pig's DML and back to Java implies that exception handling, notifications, and other instrumentation become significantly more difficult -- especially for large-scale apps, which are difficult to troubleshoot anyway on a large cluster... in Cascalog, all the extensions stay within the same language (even the Leiningen build script is in Clojure) so the compiler has a complete view of the workflow and can infer problems earlier than PIG.
The latter point is subtle but translates to $$ in practice. In PIG, you won't find out a number of problems until your app is running on the cluster. For a large-scale app, that implies burning money to test bugs which could have been inferred at compile time or on the Hadoop client prior to submit.