This seems to be the same problem as above. A block containing transactions like this one [1] that are creating P2MS outputs (1 of 3 which is strange itself) hence inflating their sigopcount (884 in case of [1] which is the highest in that block) and the miner doesn't check the limit ergo produces an invalid block exceeding 80k sigopcount limit.
The miner/mining-pool also seems to be the same since coinbase script contains F2Pool string again.
[1]
https://blockchair.com/bitcoin/transaction/0450a1fc590465796e9a1099328fdc4726b86558b7010704ae04cf2cca9643aeIt's curious that it's happened more than once over the previous days. If indeed this is a configuration error, which seems likely, someone is losing a fair amount of mining rewards I think.
That's true, specially when it is a pool where miners are trusting to not waste their hard work.
I wonder, would it be possible for a competing miner to capture these blocks and insert their own (valid) transactions in place for broadcast?
No because the block has to be changed and if you change even a single bit the final hash will be entirely different meaning it will no longer satisfy the target check so it has to be mined again.
What would be the goal or take away from a malicious node broadcasting these intentionally?
I don't think this is intentional. To give a better answer we have to know the client the said node is running which may be acquired if your logs stored the IP address of the node that sent the invalid block. In which case we may be able to connect to that node and see if it sends its useragent and that may give us more information like the client name which we could find on GitHub and report this bug.