The author has a very literal notion of "shippable". Shippable could mean to a beta group. It could mean to the public. It could mean that the feature is "done" but not turned on or it's hidden behind a feature flag.
Also, you are supposed to have retrospectives after each sprint to improve. This sounds like a discussion that should have happened with the OP's team at a retrospective.
Agreed. His argument is essentially that you can't meet deadlines with Scrum, because you must always be in a 'shippable' state at the end of each sprint.
I'd argue that if you can't meet deadlines with scrum, there's no way you'd meet them without it. His definition of 'shippable' is very narrow--like you said, just because it doesn't meet console certifications doesn't mean that it's not "doing scrum".
I wouldn't put the app I've got after the first dev sprint on the app store, either. It's not done.
Why bother redefining "shippable" just so that you can remain buzzword compliant?
Extract the good ideas, and leave dogmatic adherence to the charlatans selling buzzwords. If non-rigid use of a methodology leads to unintentionally missing out on a benefit of the methodology, whoever is selling the methodology failed to articulate that benefit.
Also, you are supposed to have retrospectives after each sprint to improve. This sounds like a discussion that should have happened with the OP's team at a retrospective.