When someone continues to cargo culting useful fragments of knowledge instead of actually learning how/why those fragments actually work, the cargo cult behavior tends to incorporate increasing levels of magical thinking.
A good example of an extreme form of this are the "sovereign citizens" that try to use their "creative" reinterpretations of legal code and procedure almost as an incantation or spell. The like to read from Black's Law Dictionary as if it was a grimoire.
Not experienced in this field but this seems like a good thing to me. Even just using crypto properly appears to be hard, and this 'do nothing when given 0' trait makes the vulnerability very obvious to a quick basic security examination (or even just looking at it in Wireshark), vs needing an expert to do lengthy analysis and figure out that you subtly fucked up the AES initialization and had been running unsafe code for years.
I'd frame it as that it doesn't matter to them. People who aren't in a feedback reward loop with the reality or with others feel no consequences, need of change or improvement. An engineer like you would generally want things to be correct regardless of outcome, but for general internet idiots or lots of startup self-appointed C-classes, sadly that is often not the case.
I suspect you might be confusing a mistake for a conflict, as described here: https://slatestarcodex.com/2018/01/24/conflict-vs-mistake/
You quite naturally see a discussion of a cipher as an attempt to find the truth, and it barely registers for you that it might not be. They probably see a discussion of their cipher as an attempt to persuade, so they use the most effective argument they can think of at a given time, and it barely registers for them that the discussion could be an unbiased attempt to find the truth.
I prefer to think of people's traits not in simple binary terms, but more in terms of high-dimensional attributes. Think: word2vec.
In practice, I find that people are messy. They have their own interests, and hence there's conflict, but they're also lazy, hence the mistakes. There's plenty of room for several kinds of suboptimal behaviour in their squishy meat brains.
Sometimes I feel like I'm The Man From Earth, watching this craziness unfold from the outside.
PS: Watch it, it's a good movie.
So for example, imagine a primitive tribe of humans facing a drought. If they spend too much time discussing options democratically, if they don't all agree, or if they waste time by changing their mind half-way to a source of water, they'll all die. But if they follow an authoritative leader -- even if makes bad arguments or none at all -- they might all make it to the mountain spring in the distance and survive.
The gist of this is that in times of hardship, authoritarian, conservative, or "right-wing" styles of though/argument/politics/whatever can win the day. But in times of relatively low stress, more democractic/left-wing/progressive attitudes can help the tribe discover even more resources than they would have if they always followed the same instructions to go to the same sources. Innovation and exploration can turn the merely adequate into a bountiful plenty, resulting in more healthy babies, etc...
So these attitudes and personality traits are important to have present in the gene pool to make the species as a whole robust against a wide range of challenges and threats.
To people like this, arguing is like punching. If you punch someone and they get up, they're a "tough opponent". That doesn't mean that punching is ineffective on other people. They just don't understand at their core that once an argument is shown to be false, it can never be reused. Their mind just doesn't work this way. They think "Well, left-hook didn't work on this guy, but maybe it'll work in that guy" or "This guy didn't fall for this argument, but maybe that guy will."
It's deeply dishonest, but I'm not convinced they're even aware of this.
So, just from a cursory look at his code, the glaring problems I see are:
1) It'll crash if you feed it more than 256MB because of the way the C# BitArray class works. He's also using 32-bit ints in several places that have similar issues. These are implementation details, but it just goes to show how thoughtless the "reference implementation" is.
2) Similarly, the reference implementation copies the entire data into the BitArrary (and then back into a byte array) for each "round". This is spectacularly inefficient. He never mentions throughput in terms of MB/s/GHz or any such thing. I wonder why...
3) It's not a stream cipher. You need to encrypt the entire file. Again, he could come up with some sort of streaming version by feeding in the last few KB of the previous encrypted chunk into the next chunk, but he hasn't. As the long history of various streaming ciphers have shown, this is actually a hard problem to solve efficiently and securely. This is why AES-GCM is the hot new thing: it's both.
4) If either the key or salt values are all 0s then the encryption does nothing. AES for comparison will still encrypt your data with some level of security even if the IV initialisation is not perfectly random or skipped.
5) He's calculating the offsets as an "int" from a byte multiplied by a byte. Hence the maximum shift is 65536 positions. This is just big enough to exceed L1 data cache on most platforms, but have a high hit ratio. Whether you hit the L1 cache or not depends on the Key & IV values, so this is a recipe for timing-based side-channel attacks. Constant-time cyphers are basically mandatory these days...
6) Related to the above: The bit shifts are only in an 8KB window, but the byte shifts are in an 64KB window. I wonder if there's some interaction here where this might make some keys insecure.
7) Despite this windowing, the default "protocol" wraps around the end of the file to the beginning using a modulo the data.Length, so it can't be used as a streaming cipher. To do so, he'd have to introduce a breaking change.
8) The encryption is defined in terms of bit-by-bit and byte-by-byte long-range operations, so there's basically no hope of ever making this efficient. E.g.: with SIMD or similar many-bytes-at-a-time instruction sets. The "state" that would have to be kept in CPU registers is over 64KB, so this is just never, ever, EVER going to compete with something like AES-NI.
I could go on, but I'm wasting my time. This is wasting everyone's time.
The author clearly has no interest in producing something that is secure and usable. He's just enjoying the arguments. He's even posted some of the feedback on his GitHub, proudly showing off the debates he's felt he's won.
Don't feed this troll.