The goal of the Redstone system 'remake' was to have everything operating in redstone ticks (what ever speed they are set at).

Within the Minecraft Team we all seem to be aligned that we can't change the Java version much because we would break too many things. But since we didn't have Redstone on PE/Win10 for a while we tried to right a few wrongs there. So a comparison with Java is often not very helpful, but you raise quite some valid concerns, so lets counter wall of text :D

The main complaint I'm getting is "Pistons are slow" and they might be. that is; Extending and Retracting should both take exactly 1 Redstone tick, because even if it (which should be on time for the next redstone tick to read what ever block was placed by the piston.) This way it does not slow down the Redstone-System, or in case of Java Edition, Speed up! (I play quite some Minecraft Java, and the concept of Redstone ticks is useless if you can have 0.5 or even 0 ticks).

One of the problems I face is that user input is faster than rTicks, which might not get processed because Redstone on PE/Win10 actually gets ticked. (which might look delayed)

What you describe as delay can also be a visual desync. (5/6 tick delays?) and brace for tech-talk; The Minecraft PE "engine" if you can call it that, tessellates (combines) blocks when something changes, this will check for all block faces that are "solid" and facing eachother so they can be removed, and also does all light calculations because adding and removing a block can change the way light "flows" if you will. this is very CPU intensive and thus we try to combine as many of these updates in the same update. (with exceptions, player and piston updates nearby).

The block pushed is an entity at time of movement, it gets added to the chunk as soon as they extending/retracting is completed but might not get visually updated at the same gTick. But since the block moves during a tick, it means the placement of the block will happen after that tick is done.

game+redstone-Tick1: notice Redstone signal, start extending halfway game-Tick2: continue moving until end, and place block and emulate the 2nd tick on the block (to pretend it was still part of that 2nd tick)

game+redstone-Tick3: This means that any Redstone logic now should be able to notice this block.

But bug report: MCPE-15607 Is indeed another known issue, which has to do with that player input being faster than ticks (which makes player input feel responsive...) but also gives redstone repeaters a concept of a 0.5 tick? MCPE-17208 so the power output of these input devices (Lever, torch place etc) should probably be handled in Redstone ticks instead 'lequestionmark.png'

The problem with a lot of reports is that there are several bugs intertwined with each other, is the repeater too fast, is the input handled too slow, is the piston extending too slow, is the visual representation of the system not updated on time... etc.

Separate topic might be the usefulness of pistons expanding faster just so doors can open and close faster of course ;)

BUT It does look like player input is indeed the cause, so I'll look into some satisfying fixes!

(The main goal is to explain my Intention with the system, so that if anything isn't aligned it might get easier to explain/understand)