Before I answer this question here's a quick idea of how I would go about implementing an infinite or endless runner.
I have worked on a couple of endless runners and they have both worked in the same way. This isn't necessarily the only way to do it but it is a way that has been proven to work.
You can create generic sections of a level that contain geometry (such as the ground, maybe some buildings and so on). These sections will also contain a spline (path) fragment. In Unity these would probably be saved out as prefabs and placed in Asset Bundles or under the Resources directory.
At runtime you would then create a number of these sections and stitch them together. (Some pieces might not fit with each other so you will need some way of recording which pieces can fit with whichother pieces - this would be some sort of offline process in the editor). Once your character has cleared a section that section will be destroyed and a new one will be created at the end of the currently loaded sections.
Now to answer your question about colliding objects:
In the situation described above, is that feasible use collider to detect objects collectable by a player running along a path?
It would be perfectly feasible to do this yes, provided the number of objects is not stupidly high. If you have followed the previous setup then objects the player can interact with can be placed randomly in each of the sections that gets generated on the fly. Usually these sections would have some predefined areas marked up for where to spawn these objects so they do not get spawned in silly places. As there are only going to be a few sections loaded at any one time and only I would imagine 10s of object at the most in each section this should perform just fine and in fact this approach has been used on a couple of games I have worked on for mobile devices.
Could be a better idea to store the location of the collectables objects inside some kind of data structure and completely avoid to use Unity collision detection?
You certainly could do this. You could store a data structure containing a position and a radius for the circle/sphere collision or some other appropriate data if you wanted to use another kind of collider. My guess though would be that its not really going to perform any quicker than the Unity collision system. So long as you don't have a silly number of objects and you know that it's not causing you any bottlenecks I'd stick with that.
What's a reasonable average number of RigidBody/Sphere Collider that can be used in a single scene on a mobile device?
Well this number is going to change wildly depending on which platform you are talking about and how much other stuff you have going on in your game. In an empty scene on a low end device you could probably chuck in a few hundred colliders and keep a nice framerate.
On iOS iPhone4 is the lowest device most developers target these days and that device is pretty poor. At the studio I work we haven't targeted the iPhone 3GS at all in any project over the last 2 years or so so I cna't comment on that particular device but needless to say its capabilities will be less than the iPhone4.
I would suggest that your bigger problem would be rendering the geometry for all of these items the player can interact with. But under a 'normal' level I guess you could probably have a good 30 odd colliders. This is a bit of a guesstimate based on working with the platforms before so don't read too much into these numbers. It will depend very much on how much stuff your game is rendering to screen and how complex your game logic is.
On Android you're going to have to deal with devices that perform even worse than that though and Windows Phone also has some really low end devices so its hard to give an exact number with so many unknown variables.
