It sounds to me a bit like what the author is saying here is that, if the source code were to get out, then it would become common knowledge how to meddle with the accounting records using a hex editor and that, in turn, would be something that an expert witness in a court of law or a tax auditor would point out to attack the admissibility of the whole system.
But that's kind of bad. If the records can be meddled with in a way that would be known if the source code were to get out, then they can probably also be meddled with without the source code being public knowledge (just harder to figure it out), and that is almost as bad: Security-by-obscurity is probably not a valid defense against that allegation if it were to come up in court.
So, there should really be some crypto there instead.
In addition to this mechanism that allows the fiscal authority to check the transactions on a specific POS for manipulation, fiscal requirements also often mandate much more, such as explicitly registering POS systems with the authority using serial numbers or hardware checksums, mandating the use of specific receipt layouts, or some kind of freeze of viable parts of the POS software which can then not be modified after approved once by the state (you can imagine how much love this kind of regulation gets from developers wanting to work under modern, agile principles...).
However, not all countries mandate such things - many still accept POS systems that basically do nothing to prevent anyone from modifying transactions after the fact (although there is definitely a trend to more strict fiscal requirements globally). These non-fiscalized systems can try to make it hard to modify transactions if they want, and many do, but they cannot make this actually impossible without having some kind of external authority in play, which is why any effort of doing so will amount to some more or less elaborate kind of "security by obscurity".
But surely: Even if a system is not specifically aiming to comply with the requirements of any specific jurisdiction, there are cryptographic things that could be done that don't cost much and are always preferable to pure security-by-obscurity. -- Just, whenever you append to the ledger, take a checksum of the ledger, append the checksum, get the checksum timestamped by a secure timestamping server (like DigiStamp or Germany's D-Trust), append the signed timestamp, and reiterate the next time you append.
That way you can guarantee that you can only ever erase the ledger in its entirety, not tamper with any single records, and even when you do erase an entire ledger, there is a record of it, if the timestamping server does that kind of journalling. -- No need to rely on any security by obscurity there.
That seems way more secure, and costs next to nothing. You don't even need to be online all the time, you can just fetch the signatures when online, and work in offline mode when there is no connection. You can even retrofit that ability when your system works with files, by putting the files under version control, and making the version control system do that. (Personally, I have my version control server rigged to do just that, in case I ever need to prove in a court of law the date when a piece of code was written etc).
That is what I meant with “every implementation that shall not just be an elaborate security-by-obscurity scheme needs an authority”.
Note that no one will ever pay for anything like that if it is not mandated by some government under which you want to operate a significant number of POS installations. It is already crazy expensive to implement all these different and mind-numbingly clusterfucked schemes that all the countries with fiscal requirements want to have implemented. The one thing no one wants to do is coming up with just one more of these schemes that the countries in which no such thing is required will not care about anyway (lawyers will not be impressed at all by technical explanations why your records are super protected against manipulation - they will still call in the armies of accountants to run the numbers up and check your books).
In some countries it isn't really the POS that does the bookkeeping, but a special device is used that communicates with tax registry (or something, i'm not 100% sure on this). All the POS software does is tell the device what it was sold, the device registers it with the tax registry and gives back some sort of code string to be printed on the receipt. This also allows the receipt to be any type of paper (as opposed to the special triple-layered paper that was often used back in the day) and even if the device itself is tampered with, the information has already been sent to the tax registry.
I think the author of this POS is mostly using this as an excuse to not release the source code, not for any practical reasons.