Their banking example is impossible under any system which guarantees serializability.

To guarantee serializability, the database system cannot assume anything about how some value is derived (unless it is something like a single stored procedure).

If I am playing the evil demon to show why their example is not valid under serializability, let us make a small modification to their example. Instead of just paying the babysitter, assume that our customer simply execute the following procedure twice as two separate transactions.

  begin transaction;
  money = select money from bank where id=42;
  if money % 2 == 0:
    update bank set money=money-1 where id=42;
  else:
    update bank set money=money+2 where id=42;
  commit;

If money = 10 initially, there is precisely one valid end state for money, money = 11. However, using the logic from the article, it is supposedly valid for the second execution to read the old value for money. Therefore, both transactions end up writing money=9 which is clearly not possible under serializability, strict or not!

The key part of this is that the database has no idea what logic we are using to compute the new value of money.

The only time I could see strict serializability potentially being stronger than normal serializability is with cases where the client is executing a stored procedure and therefore the database can know exactly what logic the client is running.