What are the disadvantages of not being able to handle huge numbers also knows and an Integer limit like in JS? I know it's not a super common thing to run into problems like that while programming so are there no disadvantages really?
Credit to justANewbie from some inspiration.
The last paragraph of my answer to Did the 2019 discovery of O(N log(N)) multiplication have a practical outcome? gives some examples of cases in which large integers are useful. Those cases, and other cases in which "big numbers" are useful, are listed in separate headings below (in no particular order).
One of the most widely known cryptographic protocols is the RSA system, and all RSA numbers are at least 100 digits long. However, RSA-100 (100 digits long) was factored in 1991 and RSA-250 (250 digits long) was factored in 2020. The recommended key size for RSA is 4096-bits or 616 digits! An enormous amount of computer security from which you benefit every day, involves computer programs that deal with numbers that are hundreds of digits long.
Polynomials are used in many areas, including number-theory/cryptography, but also for approximating other functions (Chebyshev polynomials, Taylor expansions, etc.). The more terms in a Taylor series (for example), the more accurate the approximation is to the original function. However, when a polynomial in a Taylor series has a lot of terms, it's because the variables are getting raised to large powers.
Even if we only have a 10-term polynomial, which goes from $Ax^0$ to $Ax^9$, what happens when we try to plug $x=1000$ into $x^9$? We get $10^{27}$ which is quite a huge number, and will certainly need "large integer arithmetic" capabilities if you want to keep things "exact" as we do in symbolic computation, but even if we resort to "numerical computation", the difference between $x=1000$ and $x=1000.000001^9$ is still about $10^{18}$ which is quite big!
I personally needed quadruple precision when I published this paper on the ZnO molecule. Measurements on such molecules can be done with a precision of $10^{10}\,\mathrm{cm}^{-1}$ and what I was doing, which was fitting a potential energy curve to describe the internuclear interaction between the Zn and O atoms in ZnO, to reproduce the experimental data, did not work with the state-of-the-art software at the time, so we had to switch from double to quadruple precision. Stack Overflow helped me with that, after I asked Converting a working code from double-precision to quadruple-precision: How to read quadruple-precision numbers in FORTRAN from an input file and later I asked a follow-up question on the same topic How do I declare the precision of a number to be an adjustable parameter?.
In my answer to How much does it cost (RAM and CPU) to calculate the energy of H2? you can see another example in which arbitrary-precision arithmetic is needed. I'll provide the screenshot here so that you can see how many digits are needed before you see differences in the numbers (this is the convergence precision that the authors wanted):
There's many other applications that need arbitrary-precision arithmetic. Another example is calculating the roots of a Rys polynomial for calculating electron repulsion integrals, which is crucial for tens of thousands of scientists. See the mpmath package and where it's used, to see more examples of uses for multi-precision arithmetic or arbitrary-precision arithmetic.
Using computers for "fun math" like breaking records for the largest number of digits of $\pi$, or computing Mandelbrot fractals, would also require support for "big numbers".
The question asks a double negative, so I'll answer the simpler question of what advantages there are to supporting big numbers.
To me, the main benefit is peace of mind ─ sure, my auto-incrementing ID will probably never overflow, but what if someone runs my program for a year without rebooting? I don't want to have to think about this kind of edge case, it wastes brainpower. Then there are the situations where my integers will definitely overflow and I don't want them to, but the code to handle it when it happens is more complicated than it would need to be if there was no overflow.
If my integers are fixed width and can overflow, then everywhere I use arithmetic but don't want overflow (which is a lot of places!), I need to justify why the arithmetic in that place will give the correct result, and possibly change the code to ensure it will. In contrast, when I write in Python I don't need to think about this. In many circumstances, as a programmer I'm willing to trade a bit of performance for the benefit of knowing my program will produce correct answers without having to account for arithmetic operators which don't behave like their mathematical ideals.
Another upside is that big numbers can easily be used to simulate fixed-width numbers ─ just write (x + y) & 0xFFFFFFFF instead of x + y when you want overflowing behaviour. It's much easier to discard extra bits than it is to recover those discarded bits, or even detect that they were discarded. So just one integer type (e.g. bigint) is enough for the language to support whatever integer arithmetic behaviour you want.
"Super common" is a relative thing; I don't often use large numbers in my code, but I know people who do. It mostly depends on what your language is meant to be used for; tiny esoteric languages probably don't need to worry about it, but ones meant for general use should, because someone will inevitably end up needing it.
Actual high-magnitude numbers aren't usually needed, but precision is much more often an issue, and the two often go together.
For example, using 64-bit floats to represent money amounts can quickly lead to imprecision.
An example of limited range being a problem is seen when using 32-bit integers to index an array. This limits the array size to 2³² which is fewer elements than, say, the number of humans on earth.
Most major programming languages, like C#, Java and as you mentioned, JavaScript, don't support arbitrary large integers in their default namespaces/packages/... However, for all of those languages, it is possible to support that kind of arithmetic in another way (provided in another namespace/package, a third party library, or even by yourself with custom data structures).
It does make sense to include it by default in a language designed for problems expected to deal with large integers (computer algebra systems come to mind).
Computers are designed to be maximally efficient at dealing with objects of known size, or at least a known fixed maximum size. By way of analogy, imagine one is managing a workshop with a large open floor area where people will be building various project of different sizes.
If requesting space to build a project must specify in advance how much space they will need, then one can assign a location for each project when space is involved, and anyone who needs to order supplies will be able to say when placing the order where they should be delivered, allowing the delivery agent to go directly to that location.
If it isn't possible to specify the space requirement for a project in advance, and the project grows to the point that will no longer fit in the space that's "boxed in" by the projects around it, it will be necessary for it to move somewhere else. If this might happen when anybody has a copy of the object's location and is expecting to go there or deliver something, it will be necessary to either:
Find all copies of the location that exist anywhere in the universe and change them to so they instead report the new location.
Leave a marker at the old location, refrain from reusing the space as long as any references exist to the old location, and require that anyone making a delivery look for a note to see if the object has moved, rather than blindly dropping off the shipment.
To simplify #1, one might specify that nobody other than the main office is allowed to persist any information related to the project's location, and require that the delivery agent only ask for the project's location when it's ready to make an immediate delivery, and say that if a project would need to expand between the time a delivery agent has inquired about its location and the time delivery is complete, the expansion would need to wait until the delivery is done.
It's possible for memory-management systems to use a combination of the two approaches to manage flexibly-sized objects, but it makes many kinds of operations much more complicated than they would be if all objects were assigned a certain amount of space when they were created and would never need to expand beyond that.
