There's a functional description of what ctinfo_4layercake does SQM Logic approach for Internet Bandwith management as well as background in the script comments.
Part of the point on the act_ctinfo/savedscp pairing is to reduce the need for every packet to go through a 'complicated' set of iptables classification rules. We go through those rules once for the first egress packet, make a classification decision and set that decision in stone in the firewall connmark. act_ctinfo can then reference that decision (connmark) on both the ingress (ifb4interface) path AND egress (interface) path. There is no need for every packet to go through the classification decision process which is why you don't see your firewall counters increasing wildly in the marking chain/s.
This rule:
Chain POSTROUTING (policy ACCEPT 165M packets, 126G bytes)
pkts bytes target prot opt in out source destination
406K 106M QOS_CAKE_eth0 all -- any eth0 anywhere anywhere connmark match 0x0/0x1000000
acts as the gatekeeper, in essence if the 'DSCP Set' bit in connmark is false then we need to go and do some classification work, else if it is true then classification had been done and we just carry on (act_ctinfo will do the work for us)
As regards diffserv5 appearing as diffserv3, are you sure 'tc' and 'cake module' are both patched, installed, running. Due to the extra diffserv mode the netlink parameters passed between the two need to match. I've seen this once before but I had an unpatched 'tc' IIRC. I'm not sure what appetite there is upstream for 'yet another diffserv mode' but for me it solves a problem of 'lower priority than bulk' ie. where to put bittorrent 