It's ultimately up to you, but I'd say you wouldn't just be losing out on sales, but on exposition as well. I actually bought a so-so Android device for testing because of that, since testing on a Galaxy Tab wasn't going to give me too much insight into how well my games would run on more standard hardware.
I'd say you look into doing some optimization, at least. If you can't dinamically change the framerate, perhaps you could try allowing palyers control over graphical settings such as sprite quality, the number of particles onscreen at any given time or other things that'd be minor enough to allow you to remove them without impairing the player's experience that much.
EDIT: To avoid double posting...
Writing a design document is a great way to get started. Most of the time, you'll end up changing it a lot over the course of development, but it's a great way to set guidelines for your project and assess the scope of what you're setting out to do.
Another great way to work on polishing your game ideas is to actually talk about them with others. I know many are afraid of others stealing their ideas, but one of the things you learn when you start taking game design more seriously is that nearly everyone has good ideas, but what you really need is a good framework for taking those ideas to fruition, and that kind of critical thinking really benefits from discussing your ideas and getting feedback on them.
I'd say learning though online tutorials and by staying active on Unity-related discussions will ultimately help you more than reading from books that, as you say, might be outdated as newer Unity builds get released quite frequently, rendering some parts obsolete. You should look into the three programming languages you can use with Unity (C#, JavaScript and Boo), see which one you want to use, and then read up on it. Some things about those languages will be different when you're programming games specifically for Unity, but a part of good programming is actually knowing how to solve problems in the first place, and translating the algorithms to language or environment-based implementations later. Books about Object-Oriented Programming (OOP) could be good to help you grasp Unity's component-based hierarchy, even if you aren't looking into being a down to the metal programmer. Personally, I've never learned extremely low-level stuff, but knowing high-level logic has been enough to build what I wanted to do and letting Unity handle the complicated stuff so far (why, hello, physics!).
Flexing your design muscles could be anything from reading articles on game design, to dissecting and analyzing the games you play, to brainstorming some game ideas every day and writing them down into a piece of paper with a basic description, but for programming you'd do well to learn some of the theory and logic behind it before you set out to make your game ideas a reality. In my case, I've learned a lot more from my own research and experience than the three years I've been studying game design and programming. There, I learned the basics, but you'll only get to the cool part if you have the time and desire to research things on your own and experiment a little.
