In software engineering, there is very rarely ever something that is considered superior in every respect. What's important is understanding what something is, and what problems it is well suited to solving... and what problems it isn't. And then furthermore, why.
Generally, the language is supporting arrays because that's the logical primitive of an, well, array of some type. The items are laid out in memory contiguously (I won't get into CPU cache lines right now) when defined in this way. This is just a primitive and if you had no standard library at all, you could still make an array because it's intrinsic to the language itself.
ArrayList is, indeed in most cases, a better choice for APIs and most standard usage and is implemented using an actual array, but provides easier and cleaner methods for operating on it, and behaves better with the rest of the Java generic type system. It implements the List interface which helps with writing generic code (I just need to take some list, not some specific kind of list). However, it shouldn't be seen as a superior alternative -- it is backed by the concept of an array primitive... but then again so are a lot of other data structures. Primitives map to the low level 'stuff' you need in order to get started building anything else on top of it. The closer you get to primitives the more speed and power you have, but the harder the code can be to read. A lot of software engineering is going to be understanding why these things exist and making informed choices on what structures work best for what reasons. In the ArrayList example, you have a very basic list structure implemented in the library backed by the primitives of the language. In many cases, this is what you need when you want some list of items.
Private/public and all that is another aspect of software design where the general principle is that you are writing code that others are going to use and build off of. Ignore 'protected' for now -- the general idea is that some subfunctions are easier to read or leverage if they are separated out, but they aren't intended for any code outside that class to care about. Making them public clutters the API and confuses other devs who are going to be using that class. Making something public essentially means making a contract with others, perhaps some yet-to-be-made code, that calling method X produces effect Y. If you write documentation for your methods and think of 'what are the preconditions for inputs, what is the expected output', you are basically making a contract and your implementation has to fulfill that. Getting away from the words 'public' and 'private', ultimately what you are doing is controlling what your entry points are to some given chunk of code, and letting the rest of the details be hidden.
These points are valid regardless of the language even if they are implemented very differently from language to language -- so to end this, I am going to recommend something that has nothing to do with Java. I don't have anything off the top of my head, but I'd look at some works on general design patterns. Understanding what it means to solve problems in a programming space will help to appreciate why things exist in whatever language you are using. Perhaps pick up some python -- I don't particularly like the language but for getting started it's a lot faster to actually jump into and start writing and running things. And remember, programming isn't just programming. It's software design. Programming implements that design, but understanding what it means to design software will inform your understanding of specific elements of a language. I'd also recommend taking an Assembly class (doesn't matter the architecture), even if you literally never write a line of it afterwards.
And as always -- there are always going to be artifacts in any language. Languages evolve and we learn that ways that were seen to be 'good ideas' turned out terrible. There's a reason you rarely see Vector anymore and just see ArrayList. We've since learnt the pitfalls of Serialisation and having hidden constructors to make objects and the security exploits that can open up. Properties has a bad inheritance structure that can make it confusing to use... etc etc.
It's a complex world. I'd start with the fundamentals of what it means to design good software, and how the computer is actually executing instructions for said software. A lot of the questions you have I had, and I better understood the why's once I understood things at both a lower level and a higher level (assembly/hardware for lower, general software design principles for higher)
Thank you so much for this incredible detailed and thoughtful response! I was being pretty silly with my explanation of the areas I was lacking in, but you were genuine and helped me recontextualize a lot of these concepts. Understanding why things exist and when they're useful is a better way to think about it. Much better than me rereading a textbook chapter over and over again lol. Coding in other languages like Python makes sense but I would never has tried Assembly.. we'll see how that goes. Imma give myself a project or two to work on for summer break. That'll help solidify some ideas for me. You're awesome!!