Good points. Let me give you my opinion to some of them:

We've already discussed potential solution for Hive - financially incentivise custodians to use decline_voting_rights_operation.

If the tokens are not powered up the exchange could move the tokens to a new account that can vote and power up the tokens there. So, declining voting rights doesn't add much value in my opinion. In the case of Koinos it's true that you can transfer VHP. To perform an attack in the governance system you need at least 60% of the power (or 75% to update the governance contract). In the case there is an attack by someone with a lot of tokens (like an exchange), the honest nodes have 3 weeks to react and burn more tokens. 1 week to check the proposal change, and the voting period starts in the second week (1 block produced = 1 vote). So it is similar to the solution implemented in hive, where there is some time before applying a witness vote.

Also, you still need some form of majority agreement to update core contracts, it is just that nodes don't need to stop and replay using new version of the code, because new code is just a transaction.

Correct. It is necessary to reach a consensus before applying a change in koinos. "upgrade without hardforks" means that it is not mandatory to stop and run a new code on each node. So it's easier to apply changes to thousands of nodes.

First, it doesn't matter how much support you get as a witness, once you hit top20 you are not getting any more influence on the network (you only mine one block per schedule). This is Hive.

I like this design. Maybe something like this could be rethought for koinos in the future. There are some cons btw. For instance, the witnesses with low votes do not have the chance to produce blocks. Maybe a mix between top20 and proportional stake below top20 would be a good solution.

In PoS your influence is proportional to the stake you control. Koinos seems to work that way.

Correct, this is how it works.

In Koinos it seems like it might be dependent on concrete pool contract, which raises question about practical ability of regular users to verify contract code to make sure they are not subscribing to something that limits their control.

Right now there are 2 pool contracts. I created one of them (fogata). Both of them are open source. So they can be verified by the community. It's true that a regular user will not verify it but this is the case of all blockchains. People use bitcoin without reading the code. They trust in the network because others have read the code, which is public. I think we can apply the same logic here. We cannot do more than opening the source code.

Also what ways are there to prevent pool operator from changing the contract later?

The source code of the mining pool also defines what is the procedure to upgrade its own contract. Right now the design taken by the pools is to disable this option, so it's not possible to change the contract. Later on more pools could emerge with a voting system to be able to add features or fix bugs.