As Dor noted in his answer, Scylla also offers a DynamoDB-compatible API (code-named "Alternator"), where you can get exactly the schema-less behavior you were looking for.
But Alternator's implementation is in turn based on a more basic feature that already any number of "columns" in Scylla's more traditional query langage - CQL. This feature is maps: In CQL you can have a map<text,text> column, for example, which is a single column but can put a value on a hundred different keys - and in every item you may put values on different keys, so it is similar to what a schema-less database can offer you, and may be exactly what you need.
Regarding the specific questions you asked: Indeed, empty columns do not use up disk space - so if you are concerned with disk space you can indeed have a thousand columns and only set a few of them - and not fill up your disk with zeros. However, the story is different in memory, unfortunately. Scylla's in-memory caching of these rows is not sparse, and empty columns do take up memory. Not much, but some. So having literally a thousand columns in your schema and only setting a few in each row would be wasteful in memory.
In my answer a few years ago in
https://stackoverflow.com/a/47127723/8891224 is tried to explain why schemas were added to Cassandra (and thus Scylla, which was based on Cassandra). The main historic observation was that most people did not reach the situation of "1000 columns" because they actually designed 1000 individual data attributes and each item only has a handful of these 1000 attributes set. Instead, what usually happened was that these "1000 columns" were usually really a list of perhaps 100 separate "items" with just 10 attributes each. Cassandra's and Scylla's (and DynamoDB's) concept of clustering key was introduced as a better model for these 1000 columns. It is still possible that there are optional columns that are not defined for every item - but then it's not "each item has just 10 out of 1000 columns set" but perhaps "each item has 10 out of 15 columns set" - which is perfectly acceptable performance-wise.
I also explained in that above-linked answer that schemas were introduced to Cassandra (after it started without schemas!) because they serve an important purpose: They make it easier to write a correct application. A schema-less database makes it trivial to add another column to the application just by using it in some new code - but also makes it easy to use the new column inconsistently in the code. In schema-full Scylla, you need to explicitly add the new column to the schema (you can - but you need a special ALTER TABLE command to do it), and then Scylla verifies its type every time you use it (e.g., you can't accidentally set the column to a string in one piece of code and a number in another).
