The size_t/int64 refactor has been going through several iterations and RFCs since 2013.
They could have been integrating the changes in their code as they went, and then launched with 'Hey, we have this cool new project, including the optimization work that people have been doing'. Instead, they kept their work secret, knowing that their work was incompatible with another large refactor that people were contributing to, and then said 'hey, abandon all the work you were doing because who cares'.
The thing is, that is all being achieved despite how badly the internals is run. Seriously, I tried to get involved and was turned off entirely by how it's run as an "old boys" clique where new developers and changes are considered enemies. It's really sad, and I think PHP could become a much nicer language overall if that changed. Some people who are far smarted than myself have the same opinion too, so it's not just me...
In particular, their primary advertised concern was on the 4% increase in memory usage - but the whole purpose of phpng seems to be to make PHP more compatible with JIT compilation later on - and that seems to almost universally requires large amounts of memory to work really well.
Then, the arguments made in the discussions were basically besides the point. Overall memory usage is not really important on modern hardware, since memory is cheap. The real concerns are time performance - if the performance is degraded, it would be a valid reason to reject some of the changes. The vast majority of criticisms were just along the lines of 'but why do we even need 4GB+ strings' - I can see exactly why Pierre would get frustrated at having to parrot the same line. Performance in current php was clearly fine, and performance in phpng was only ever mentioned in completely vague terms - the most empirical it got was 'i guess 20-30% worse' which isn't really a trustworthy figure by any means.
The burden there was up to the phpng team to recognise that there were changes in the standard php pipeline that would potentially invalidate some optimisations. Coming in at a late stage and saying that it would ruin everything, having made no effort to stop someone wasting much time, was at least inconsiderate and probably rude also.
Then attempting to effectively filibuster the situation by repeatedly firing irrelevant arguments at Pierre, then recruiting randoms to try and vote against it as some kind of 'we are being undermined' campaign, then trying to change the voting rules, it all just smacked of a very amateurish and/or rude community. Yes, they were mostly by the same people, but at some point someone could have very easily come out and pointed out (for example) the inherent fallacy in the 4GB+ argument, or the fact that the phpng developers should have informed Pierre earlier that their new optimisations might conflict. It seemed like a number were happy letting some fight their preferred argument with the wrong reasons.
The arguments of 'wasted data' aren't convincing - the arguments of 'wasted data causes poor performance' would be convincing were there any data whatsoever to back it up, and if those who argued actually worked from that standpoint.
My problem was (as someone who read the mailing list) was simply that the very real concerns were brushed under the carpet, and that the situation was allowed to develop in the first place.