If the main motive of the lockup period is to

ensure that attackers will lose $$ if they wanted to attack the Hedera network, then perhaps we should continue to explore what other options there are to achieve the same goal without the need of a lockup.
After all, all the lockup does is adding some friction to the attacker when it comes to selling their HBAR to prevent loss prior to the attack, but doesn't prevent the actual attack from happening if the attacker doesn't mind losing $$.
So really, the main focus here is: "How can we ensure that the attack is expensive?" or "How can we discourage attackers from thinking about attacking the network?" instead of "How can prevent the attack from being successful if it occurs"
Furthermore, and importantly, retail HBAR holders can get in a undesired scenario where they cannot sell their HBAR to limit loss if they found out about the attack > 48 hours later. This in turn will damage the retail confidence and faith when it comes to staking their HBAR and this will have a cascading effect on the security of Hedera as a whole and in the long run. We cannot expect that most retail users will stay up to date with the health of the network on a daily basis
Liquid staking is attractive because you can unstake anytime to limit loss following an attack, so is therefore less risky. This in turn will attract more users (and whales) to our network and therefore HBAR will be better distributed throughout = better security. I know users who couldn't unstake UST / LUNA during the crash because of a prolonged lockup period and they had to take a massive loss. These affected users will think twice about lockup staking in the future.
In my mind:
• Lockup staking = better security but risk adverse users will avoid it = less HBAR distributed = lower security
• Liquid staking = good security and is risk free, and therefore more users will sign up for it = more HBAR distributed = better security
Therefore we should keep exploring how we can add more friction to ensure that the attack is expensive or impractical with the liquid staking option without the need of a lockup.
For example, have these ideas been considered:
1 Have an upper limit of maxStake to prevent having too few malicious node holding too much stake. That means the attacker would have to purchase a significant amount of node hardware in order to carry out a 1/3 or 2/3 attack within a shard which may not be practical enough, and with sharding it's even harder to organize the 1/3 and 2/3 attack because each shard will have random nodes (From what I understand). And optionally, GC nodes, Permissioned nodes, and Permissionless nodes could all have different upper limits for maxStake to reflect the risk level of each node type.
2 Add measures to ensure that GC and permissioned nodes have at least 1/3 stake (combined) per shard. But this may become impractical to do when we have many shards and we may not be able to guarantee that each shard have permissioned and/or GC nodes anyway. But point 1) could come in effect if there is an upper limit of maxStake.
3 Whenever a significant amount of HBAR is unstaked from a shard, and is enough to affect the consensus, propagate an event through the shard to trigger the process to update the stake amount of all nodes within the shard at next fixed interval (on the minute or on the hour, to prevent spam).
There could be other ideas I haven't though of yet.

Read what you posted, aftee his In my mind he is pro liquid staking not lock up.

He is pro liquid staking but its not more secure as you say.

I said there is no difference for attacker if staking its liquid or lock up. While there are other consequences for lock up

For attacker it is sacrifice a total write off of Hbar holdings anyway, while making money on leverage short. They would not care if is locked or not at all