Is this a premature optimization, or is this an important design decision to make? If the data is stored in component objects, will it make a difference anyway
It can be. I argue strongly that developers should use much simpler component architectures and utterly avoid ECS. Having a vector of pointers to IComponent objects with a virtual Update() method works well for even many big AAA games.
However, once you need to start squeezing performance out, architectural choices can leave you painted into a corner. Converting a million lines of engine, tools, and game from a naive component architecture into something with decent memory access patterns is a months-long process that is simply infeasible to carry out for a game company with multiple developers and a real timeline or budget.
(won't the references to those objects be stored sequentially, and not the actual data)?
The idea is that you store the _actual objects_ in contiguous memory, not just references. e.g. you have a vector<FooData> and not just a vector<FooData*>. This of course is not an option in languages like Java.
If you're in a language like Java _and if you need the peformance_ then you're in for a hard time. There's a reason that Java isn't used often for high-performance anything. The Android games where performance matters don't use Java; they use the NDK.
If you're just writing a small/simple Android game or just learning for the first time, neither Java nor memory access patterns will be your bottleneck, though. Ignore the performance advice and just stick to simple, easy-to-understand, easy-to-modify code. Your big bottlenecks are going to revolve around how you draw, how your AI works, etc. Optimization is usually algorithmic; it's not until you have a ton of experience and are truly pushing the hardware that you'll really _need_ to start optimizing memory access patterns.
That said, lazy coding and bloated runtimes are why smartphone batteries still only last for a handful of hours or why your desktop in 2015 feels no more responsive than they did in 1995...
If I'm planning on this engine to be used primarily for mobile platforms does this matter more, or less (I know in Java, you are kind of at the mercy of the JVM for stuff like this, objective-c, I'm not sure)?
Objective-C is a native (non-interpreted) language; it has some higher-level primitives than most other native languages, but you can avoid those for the most part. You can of course write the vast majority of your game in C or C++ and then just use Objective-C for the few platform integration bits where Apple forces you to use it.
Likewise on Android you can use the NDK (Native Development Kit) and completely avoid Java/Dalvik and instead write C or C++ for the majority of your game.
There are cross-compilers for other languages like C# that target these native layers, so you can use "improved Java" languages like C# or modern high-level languages like Rust if you aren't into C/C++.