When breaking a block with block entity data, in the event that the break is denied by the server (such as when breaking blocks in spawn chunks), the block entity data is lost until the chunk is reloaded from the server.

Attached are an image of a sign and a banner in spawn chunks, and then another image of what they look like after attempting to break them as a non-opped player (which causes the break to be denied by the server).

The data is lost until the block is re-sent to the client, such as by relogging. My analysis is below (copied inline from here).

When breaking a block, the client will start a prediction about the break process via MultiPlayerGameMode#startPrediction, and immediately trigger the break on the client.

While the prediction is "active", changes to the block sent by the server via ClientboundBlockUpdatePacket will not be commited into the world, instead being delayed until a ClientboundBlockChangedAckPacket is sent (which will happen next tick). This process allows the client to reset the player's position if they moved into an illegally-broken block.

Since the block change is not committed into the world, other packets that rely on the block change being committed (such as ClientboundBlockEntityDataPacket) will be discarded, meaning that when a block is broken on the client but denied by the server, the BE data is lost from the client.