Here are the spirit that Soya follows (or should follow ;-) ):
Soya's goal #1 is to allow to develop as rapidly as possible 3D games and other 3D apps (Rationale: Soya targets "amateur" developpers, who code during their limited free time! Moreover, rapid development allows to gain a precious time that can be re-invested in improving your code or testing your app. For game, it leads to a better gameplay)
Soya's goal #2 is to be as easy as possible to learn, in particular for people with no 3D background at all (Rationale: Soya is not a toy; to be easy to learn is only goal #2 since any newbie will, a day, not longer be a newbie)
Despite its simplicity, Soya never sacrifices performance and speed (Rationale: speed is important for 3D game!)
Soya's API does not necessarily fit to the mathematical, computational or technical reality of the 3D, e.g. Soya API does not require the use of matrices (Rationale: math are not the natural way to represent 3D object. Soya should be useable without an important mathematical background. However, Soya provides matrices, mainly for debug purpose)
Soya relies a lot on Python facilities and modules, e.g. saving 3D model is done with the pickle module. As a consequence, Soya won't evolve toward a multi-language 3D engine and will stay Python-centred (Rationale: Python modules ease the Soya development, but also the use of Soya, since they are already well-known to Python developers)
Soya has plenty of dependencies (Rationale: any good OS has a package system tools today)
Soya always assumes by default the most common usecase (Rationale: doing so lead to a substencial time gain)
Soya is an "atypic" 3D engine and relies on a certain number of controversal choices that are somehow debatable ; however, most of these choices are deliberate (Rationale: Soya should be seen as a "research project" aiming at "a new way for 3D" ; the objective is not to satisfy anyone, but to be the ideal 3D engine for a few persons. Python does similarly)