Problems should not only be safety and scalability.
These are the main ones, the security of types, which has to do with robustness, and with the ease that typing makes it possible to manage large databases since the compiler and tools, such as IDE, can help detect errors and prevent misuse, and better organize. When you have to think about guys people tend to produce better codes.
Not for nothing, programmers of dynamic typing languages tend to be weaker than those of static typing. And it creates a vicious cycle, where these languages that no longer value robustness attract many low-skilled programmers, and precisely because they train in language that no longer requires them to think, they rarely become better programmers.
Of course there are exceptions and there are good programmers using dynamic languages, but it is the exception and not the rule. And it is common to have a Dunning-Kruger effect. And obviously many bad programmers use static languages.
The other reason not cited is the loss of performance. The computer is typed by nature and knows how to handle certain data natively, pretending that there is no type requires having a mechanism to make it work and this has cost.
Must have design problems there that I haven’t seen be discussed
Design who does is the programmer, not the language, so it depends on it. Dynamic typing lets do designs horrendous and may even work. Static typing also allows, but less. But of course, with "will" everyone can do the worst designs possible using any tool. I would prefer people to use all this willingness to produce more interesting things.
But the suggested question is to handle everything as string, what is known informally and jocosely as stringly typed, in reference to strongly typed.
There is an obvious loss of performance because any calculation to be made needs conversion, and treat a array of characters costs more than dealing with a number. And it needs checking before using, and treating errors that wouldn’t exist if you already knew the type of.
In this case, it’s not even a problem of having dynamic typing, it’s treating everything as one thing, which is even worse. Unless everything is description. Where only describes data changes little, after all the right type for descriptions is the string.
If you are going to do other operations you will have to do conversions every time. And check if it was possible. In many cases you will have to create auxiliary functions for this, and only after this do some operation. All this costs expensive to perform and to develop, it is complex and gives space for various problems to occur.
An example: the user creates a field to save date. There he wants the amount of days late for today. How to do this with something that is just text? Recreating everything that already exists as date. Slower, more complex and less robust.
Flexible software
Actually doing what was described in the question is something far more complex than people think it is, and even experienced people are trying and doing it wrong. You have a lot to think about, and in the end you will practically create a compiler and a new library to deal with this properly. And you’ll probably fall for what’s called Greenspun’s Tenth Rule Of Programming:
Any sufficiently Complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
-- Philip Greenspun
That is, people tend to invent sophisticated mechanisms for simple problems, and tend to stop using what they already have and choose the best decision of design.
The problem is also known as Turing tarpit tends to a Inner-Platform effect or adopting the peter’s principle. See also: https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles.
You don’t understand why I put these links?
Did you stop to think that letting the user create data the way they want without giving them the power to program something is for nothing? Unless it’s all descriptive, which is never a problem and doesn’t create any difficulty.
If you’re going to program on top of what they’ve created, then it’s easier for them not to create, after all, in theory, you’ll be able to create better than them and it’ll be less work. The only way to make sense of this kind of mechanism with any reason is to create a complex broad infrastructure to deal with what the user will do.
It improves a little if it is already a type of date, then at least you can use what you have ready, without having to convert and already validated. But it is not yet simple.
In general this type of flexibility is best adopted to consume existing data and not to create it. Then a layman can do it without major problems, if it is not something complex. And if he makes a mistake, in consultation there is no potential to cause much damage. Even in these cases it does not serve for all.
Note that the problem is not just storing everything as text, it is storing something without semantics. Everything gets more complex to deal with. And it helps little. Even if you use other types, it may not be enough.
Engineers already make a lot of mistakes design systems, which ends up being normal given the difficulty we deal with. Programmers who are not engineers do very wrong, almost always. Imagine user (I know some better than certain "programmers"). Do not give match to play child.
After decades working exactly with the described question I know what can give the user and what can not, what facilitates and what is decoy, what is good for the user and what is only facilitator for the programmer. The summary: give little, and if absolutely necessary, and only know how to do it very well, which is much more complicated to do.
Developing software is difficult, unless in very trivial cases and they already have a solution ready, which should not require new software. And it’s engineering, don’t be fooled. The user doesn’t know how to develop software because he’s not an engineer, just like some programmers are not.
Some may think this is ivory tower or aquarium syndrome (old term for IT personnel who closes in their department and does not want anyone to meddle). But we see all the time bad users and bad programmers doing horrible things because they don’t understand what they’re doing, and that’s clearly a bad thing. It is so much that it is almost impossible to find the exception that confirms the rule, even if it exists. Leaving it in the hands of the user does not usually work.
Read this: Using client validation is sufficient?.