No, it is only when you require your upgradable contracts that you should use the ZeppelinOS framework; otherwise, it is better to use Truffle.
No, you should not have constructors defined for your upgradable contracts, as contract initialization is performed via the Proxy contract.
To achieve true decentralization, you need to ensure that future rule changes are not allowed in contract. Using the immutable property of blockchain, smart contracts are made immutable so that the logic or rules cannot be changed once deployed; however, using a ZeppelinOS-like framework, you can create contracts that can be upgraded in the future. This is a centralized form of control and not a decentralized form of control. When using upgradable contracts, your users cannot trust your model, as it can be changed at any time. Hence the ZeppelinOS framework should be used only when you need extensive centralized control of contracts; otherwise, for pure decentralized systems, you should avoid using ZeppelinOS or upgradable contracts.
If your upgradable contract has a state variable that was initialized only once, that variable can be reinitialized using the upgradable contract's new definition. You can write a new function to reinitialize that variable to a new value. Ensure that only the authorized person is allowed to reinitialize this state variable.
The implementation contract address is stored in the Proxy contract of upgradable contracts. This address points to the implementation contract to which the function calls are delegated by Proxy. The implementation address is stored at a random location in memory so that it does not conflict with the other contract state variables stored in the storage.
Users and admins should not call any functions on the implementation contract. This implementation contract is only used to refer to the function definition; the actual function is executed in the Proxy contract context. Calling functions directly on the implementation contract does not make any change to the state variables of the Proxy contract, and hence, it should be avoided. In fact, sometimes it is better to restrict calls on the implementation contract.
Logically, you cannot remove an existing state variable from the contract. If you want to remove a state variable in the upgraded version of the contract, it is better to rename the state variable and remove references to it from the contract, but you should not remove the state variable completely from the contracts. At the very least, the state variable definition must remain in a new contract.
