Databases used to very much prefer records with fixed sizes. (they still do, but they used to, too) And storage was very, very expensive so these fixed sizes were often the smallest they could conceivably get away with. So there'd be a record in the database, and you might have 10 bytes for the last name, 10 for the first name, and 8 bytes for the password. When I was younger it was super common to see the first 10 letters of my 11 letter last name on official documents. Not long after 9/11 I was hassled by airport security because my last name on my ID "didn't match" the last name on my boarding pass, until an older wiser airport security person explained to him that it was normal for the boarding passes to cut off after 10 characters.

Early versions of BASIC were limited to 2 character variable names. Some would allow you to use longer variable names, but only the first two characters would determine which actual variable it referenced. So if you had the variable JOHN and the variable JOAN they'd alias to the same value. Later versions of BASIC extended this to 6 characters. This was seen as positively extravagant.

Many filesystems used 8.3 filenames; you had 8 characters for the stem and 3 characters for the extension. Sometimes people say that this was just an MSDOS thing but it was common on many other OSs at the time. I'm 90% sure CP/M had this limitation too.

Lots of examples (e.g. maximum number of nesting levels), see for example:

http://www.tendra.org/tdfc2-config/chapter2

https://www.ibm.com/docs/en/epfz/5.3?topic=reference-limits

One aim of finite implementation limits is to define which programs are guaranteed to compile successfully, so that you don’t run into the situation that a program compiles on one implementation but not on another implementation, which would raise the question of whether it’s the program or the compiler that is nonconforming. If both are conforming, you want the program to compile 100% of the time. This isn’t possible if programs can have unlimited complexity.

The mindset is similar to embedded programming, where you have limited memory and absolutely don’t want to run into the situation that there’s not enough memory left to perform the operation that needs to be performed.

In the embedded world you're always mindful of memory consumption. Static allocation of a fixed size array has advantages over the same data in a linked list by simple virtue of eliminating node pointers and bookkeeping overhead associated with dynamic objects. Regardless of concerns about algorithmic complexity. Sometimes you really do need to set fixed limits for the sake of economy.

Minicomputers of the 70s and PCs of the 80s had computing resources comparable to what passes for embedded systems today (i.e. much less capable that an RPi). Those machines required tradeoffs with arbitrary limits to make realizable software and that is still a valid approach for a subset of modern programming where you can't just pretend you have an infinite store that will never be exhausted and if you do hit a limit you can't just throw more hardware at the problem.

Dynamic allocation can often use up less memory, since it only reserves as much as it needs, not the maximum for every item.

Early C compilers had a limit of 6 characters for an identifier