There's some explanation in the original design proposal here: https://t.co/An1ZpRSu7O .
Basically, it was meant to use some OOP features to provide a convenient abstraction for contracts. Objects' data could be arbitrarily complex through its
mapping mechanism. The original design included the ability to specify (and therefore optimise) that mapping. For objects' functions, I leveraged the then-new Ethereum contract ABI specification to synthesise something familiar to OOP practitioners. The introduction of the
constant function marker was also quite nice, since it allowed an optimised way of inspecting object state with Solidity logic.
It was meant to be a sophisticated tool for developing contracts that could ultimately give both developers and users good information on what the code did. To help this along, I devised NatSpec, a contract-friendly documentation format, and made that a first-class citizen in Solidity. I also proposed a formal proofing language subset (not yet implemented) in order to maximise the kinds of correctness guarantees that could be made.
I introduced events as a first class citizen into the Solidity language in order to provide a nice abstraction for
LOGs similar in form to function calls. Inspiration for that came from the Qt meta-object system's "signals".
One later feature that Christian R. and I figured out together was function modifiers; that allows attributes placed as part of a function signature to make some modifications to the apparent function body. Being a very declarative means of expression, it's an idiom that falls nicely into the contract-oriented programming space.