Good points. Tendermint aims to be a general purpose consensus system - how the validators are actually chosen and changed is outside Tendermint's domain.

All Tendermint wants to know is an initial set, and leaves it up to the App to tell it how the validators should change with every block.

You can build PoS at the application level, if you need it. This is what we're doing with https://cosmos.network/. With every block, the application can decide, according to its particular PoS design, how the validators should change.

There's actually no reason you couldn't build a Tendermint app that determines who the next validators are based on PoW they did and submitted as a transaction. Not quite the PoW we're used to, but it shows Tendermint is quite flexible. That said, a 2/3 coalition of the current validator set always has complete control on what goes in the blockchain, and a 1/3 coalition can halt it - we can't bail out of that without a hard fork.

Note PoW is also only safe in a synchronous network, though it hedges this with an economic random lottery. Of course PoW guarantees a thermodynamic immutability that nothing else can.

Tendermint isn't inherently economic, and is safe so long as <1/3 of the validating power is malicious, even in asynchronous networks. That's what Jepsen shows here (well, fails to disprove).

Arguably, Tendermint is most useful as an analog of Paxos/Raft but in a multi-stakeholder, or otherwise more adversarial, setting.

We aim to prove it's also useful for structuring global financial systems and scaling cryptocurrencies :)

Unlike traditional BFT algorithms that have multiple validators with equal and static voting power, what Tendermint does is each validator has coins staked to them. These coins can be either the validator operator's own coins or coins that are "delegated" to them by other users (think of these as Proof of Stake "mining pools"). Their "voting power" in the BFT consensus is weighted by their coin stake.

Validators can come and go as part of the protocol, so essentially the previous validator set signs on the next validator set. Also, more people can delegate stake to existing validators.

When a validator leaves, there is an unbonding period before they are allowed to withdraw their coins (this is the to put a minimum time length on a long-range attack). Tendermint also solves the nothing-at-stake problem because if a validator doubles signs on two competing blocks, this is byzantine behavior that is recognized and punished by slashing their staked coins on both forks (staked coins act as both weight for BFT voting power and as security deposits).

One assumption that Tendermint makes as opposed to Nakamoto Consensus systems is that at least 66% of validators have to be running in order for the system to make progress. In Nakamoto consensus, even if a lot of miners are down, the existing miners can still propose blocks. This is, however, a double edged sword, as what seems top be "down validators" might actually be a network partition. In Nakamoto consensus, even a temporary partition would lead to parallel forks, while in Tendermint, this would not happen, as the system will stall instead of forking. Nakamoto Consensus is availability favoring, while Tendermint is consistency favoring.

Tendermint works very well for both Proof of Stake and Proof of Authority systems, which is makes it particularly useful for both public and private settings, and deals with byzantine faults in both, as opposed to just crash faults as in protocols like Paxos and RAFT.

Tendermint is a BFT algorithm implementation and state machine replication system. The app(state machine) can implement a proof of stake protocol.

Proof of stake functionality is provided by the cosmos sdk which is under development.