Hi Marco,
this is as you are properly expecting by design and is a common pain in multi-language deployments.
It's applicable to every language-enabled objects, starting with so basic ones as system tables (MAXLABELS, MAXATTRIBUTECFG, etc.) ending with ons like ITEM and ASSET.
Based on my experiences, in deployments as yours, where there is EN as base, while secondary language is mainly used, then customer typically was deciding completely disable language support for these tables. For site-level objects (like ASSET and LOCATIONS) doesn't make much difference, as entries are typically "language-specific" anyway. With ITEM catalog (potentially cross-organization) this is not so obvious choice but this still can be done.
Alternatively, if you don't intend to disable ML-support then e.g. you can set up a escalation or cron taks which for every newly created asset performs the operation of reading asset data in ES (open MboSet with: ui = getRunasUserInfo().clone(); ui.setLangCode("ES")) and populating the very same record in the separate MboSet, this time opened with EN (ref. previous code snippet).
Of course this is not instant. Furthermore it does not cover "update asset description in ES description" but with a bit additional rules you can probably come up with which covers your case. I'm not sure if it's worth a trouble. You need to assess the options yourself.
//Andrzej