Executive Summary

Excluding Big-Integers, Strings that are more than one character long are inherently more complicated than numbers because they:

• are represented as a list (or shallow tree) of multiple numbers
• can be alphabetized
• have case sensitivity
• have punctuation, accents, characters, and whitespace, which all need to be treated differently
• have character encodings which add their own complexities.
• could use a lot of memory (if large enough).

Big-Integers could be about as complicated as all-lower-case (or all-upper-case) ASCII or EBCDIC strings.

Details

What's a String?

A string is a list of characters. Characters are just numbers and a character encoding that gives each character a number to represent it. So a String is essentially a list of numbers.

What's a Number?

Excluding a few special-purpose computers at research facilities, every popular processor has built in integers (from 8 to 64-bits) and IEEE floating points (32- and 64-bits). Popular processors have instructions for doing simple math: +, -, /, and * on these various kinds of ints and floats. Popular programming languages have straight-forward syntax that gets compiled to these opcodes in very simple ways.

Bigger Numbers?

Many languages have a Big-Integer that stores values bigger than what fits in a hardware 64-bit integer. Like Strings, they are essentially lists of numbers. Sometimes BigInt is implemented as a String, but I hope that is rare today. Like Strings, BigInts tend to be harder to use than simple hardware-supported numbers. You can fill up memory with them, etc. As an aside, tools like Spire cleverly promote Integers to BigIntegers as appropriate.

Character Encoding

Strings used to be encoded in EBCDIC, ASCII, WinAnsi, and a bunch of other formats that came out before Unicode. With Unicode, there is UTF-8, UTF-16, UTF-32, and other ways of representing characters as one or more bytes. Some character encodings are one-way compatible with others, but most are not. ASCII has only 8-bit characters, but a String in UTF-8 is actually a shallow tree structure where each character is composed of 1-4 bytes (thank you @gnasher729). And that's just representation of a single "code point" in bytes. The logical characters themselves are sometimes composed of multiple code points (a base character plus an accent) so you have grapheme clusters to deal with (thank you @gnasher729).

Parting Thoughts

Anything can be as complicated as you want it to be. Numbers can be positive, negative, or zero (IEEE floating points can also be negative zero). They can be even, odd, prime, ratios, imaginary, irrational, transcendental, or have many other properties that have kept number theorists and set theorists busy for centuries and will continue to do so.

But character strings represent languages and you need fonts to render them, which have their own set of headaches (and licensing issues). Chinese people whose ancient family names involve characters that are not otherwise part of their roughly 10,000 character alphabet are clambering to have their names included in Unicode. There are lost languages, and arguments about whether made-up languages like Klingon need to be included in character sets. I think when you add all that, plus regular expressions, then in general, Strings are more complicated than numbers.

Probably for every string complexity issue, a great student of Math could bring up various series, sets, divergence, and other complex issues. But I think you are defining numbers as "ints, floats, and maybe Big-Integers" not as "polynomials, series, and beyond."

This depends clearly on the programming language.

For example, when using a language focused on numeric processing (like Fortran), or when using a language like C where "String" is not an inbuild data type, or at least not implemented as seemlessly and without a concat operator like "+" or "&" and garbage collection (like in Pascal), then string processing can "feel" more complex than number processing.

However, even in old languages like Basic, or modern languages like C++, C# or Java, where strings are either a core datatype, or provided as if it was one, string processing is IMHO not more complex than dealing with any other core datatype. And this is even more true today for scripting languages like Perl or Python, which provide you with a powerful collection of string tools and functions, which make string processing very easy, once you learned those tools.

Its down to memory - an integer variable, for example, will occupy a set number of bytes and will never grow or shrink. A 4 byte variable remains like that and is copied around the system as-is, This means passing one into a function copies the value directly.

Strings however, occupy a variable number of bytes and this makes them fundamentally different to simply primitive types like int. If you copy a string into a function, you're really copying a reference to the start of the string rather than the entire string itself. (some programming languages then mask this to make operating on the string appear like modifying an integer, for example changes made inside the function are lost when the function exists)

This memory issue also shows in how to tell if a variable is not assigned - a string can be null for example, whereas you'd have to use a special type to represent a nullable integer (in C# for example), showing the cracks in any system that tries to manipulate strings and ints the same.

Another aspect is the complexity of strings anyway - integers do not have replace, split or trim functionality to name just 3, so strings are just more complex by their nature.

And lastly, encodings are present - how a string gets presented and what the meaning of each character is changes depending on the system or encoding used.

So yes, strings are just different to the primitive types. That's just the way things are.

In my opinion, we use numbers, don't process them. If you are doing some kind of numerical analysis (which I do often) in any language, you'll use the numbers as input for formulas, for example. This is of course not necessarily always true, but usually true.

Strings are "processed" more.

For example, you don't make a script to put numbers to lower case, or separate them in words, or take out certain parts. At least, is not that common.

So, I would say is not a language issue. Is just that numbers and strings have different uses, and are used in a different way. My two cents.

Also, I would like to make an emphasis that I think this is usually true, but not always. There have to be people who "process" numbers the way most people do strings, but is just not that common.

I think there are two aspects to this, and your question was not entirely clear which direction you want to take.

String operations from the perspective of the programmer can be easy depending on the language. Perl, for example, has regular expressions and other string operations baked into the language. It is trivial to transform or search strings. Other languages such as C require standard library calls which are cumbersome to use.

Under the covers, string operations are necessarily more complex than numerical operations. CPUs have built-in instructions for integer math. What does that even mean in the context of a string? Modifying strings: concatenation, truncating, etc. This cannot be done in the context of a single CPU instruction or register, making the implementation more complex.

Furthermore, what encoding does your string use? While integers have fairly standard semantics (so do floating point numbers), strings have many encodings (normally some form of Unicode or an ANSI code page). Code that operates on Unicode strings must necessarily be more complex than code that operates on numbers. How do you concatenate a UCS-2 string with a UTF-8 string? Compare them? These operations are possible, but there are now multiple steps involved: decode to get the Unicode code point, then compare or concatenate code points. When creating a new string in such a case, what is the new encoding?