But another way to have this job done is to "set some (existing) object's parameters": how is the load of a llGetObjectDesc/llSetObjectDesc?.. really little I think ('cause it not involves UUID's creation/deletion but parameter's change only).
Thus LL should build a new "Storage Object" (SO from here) which can hold a number of description-like memory areas, each one 256 byte size, and all the "object" should be read/writable using an index, like we do with lists (0..N: with N = 64 we'll have a 16KB storage, with N = 256 we'll get 64KB ).

llSetStorage(string objectname, integer index, string var-to-write)
string llGetStorage(string objectname, integer index)

with:
objectname is the name of the StorageObject in the prim's inventory where the script resides
index is the "row" we want to Get/Set (Read/Write), 0..N (0..63, 0..255 and so on: we don't really have a limit but the "frame" set).
var-to-read/write is a string which can cast to/from the original/target data type (e.g. integer->(string)intvar -> (integer)stringvar)

So, doing a llSetStorage(storage-object-name, N-row, (string)var-to-write) I can write and, obviously, with (type)var-to-read = llGetStorage(storage-object-name, N-row) I'll read a row/value/something. Index can be negative, as some other LSL statements allow, to idex "from the end".

Storage Objects 're similar to Notecards and other SL objects, so can be put in and out from Inventory to prims, transferred like scripts to objects/prims and so on, generating a unique UUID allocation into SL DBs: no more danger for UUID spam-allocation, malicious scripting and so on.
More: with the LSL-editor one should be able to (read and) write a S.O. interactively, as editing normal text: each 256-chars line is a LSL-indexable "record", so that we can write our config files directly: just Edit -> write (scribble scribble) -> Save and the SO is ready to be put into our vehicle, gun, spaceship and so on.

[enhancement]
As I read in SVC-1406's comment by Alvargi Daniels, one record of the SO can be reserved to the creator only: the last SO record (index = -1) should be writable only by the SO's creator and should be read-only for any other.
[/enhancement]

The Storage Object's architecture/features can be extended as wanted: LL can create a statement which reports the "status" of the SO, like "empty", "full", "n/N row used" and so on, or one to perform a full-one-time-write (and read) a SO using a list instead of single strings (which I proposed to lesser the memory load), SO's write-protections mechanisms, record lockings and much more... but what the SL community is asking for, nowadays, is a (possibly) simple and reliable way to write down some info on a support which is less volatile then scripts variables.

Ah... a little last thing: Storage-Objects, if really made, should have a "storage disk" icon in memory of their long awaited birth.

Elwe

note: no UUID/asset server have been harmed to write this issue.