This is a very popular question on Stack Overflow, and that made me develop a sort of "standard response" to it.
1. Why are you trying to bargain?
First off, the question sounds like you are trying to bargain yourself some "discount" in the development. But why you're trying so? Why such a question ever arises? Are prepared statements too hard to grasp/implement for you? Then you should ask a different question, "How do I make prepared statements less tedious?" In fact, a prepared statement is easier than any other method of database interaction.
So, in the first place, there is no reason for such a question at all.
2. SQL injection is only a side effect.
You need to format your queries regardless of any possible threats. You are doing it, not for the famous Bobby Tables, but for a humble girl Sarah O'Hara in the first place (or any other human or entity who happen to bear a name that could make a database choke, if not formatted properly).
So, it is not an SQL injection you must be using prepared statements for, but merely to guarantee that your query will be always syntactically correct.
3. There are too many possible pitfalls with manual formatting
Using no prepared statements means you are resigned to format your data manually, and there are a lot of pitfalls on this road. I endeavored to summarize them in my an article on SQL injection. Here is an excerpt:
Manual formatting can be incomplete.
Let's take the Bobby Tables' case. It's a perfect example of incomplete formatting: a string we have added to the query was only quoted, but not escaped! While, as we just learned from the above, quoting and escaping should always go together (along with setting the proper encoding for the escaping function). But in a usual PHP application which does SQL string formatting separately (partly in the query and partly somewhere else), it is very likely that some part of formatting may be simply overlooked.
Manual formatting can be applied to the wrong literal.
Not a big deal as long as we are using complete formatting (as it will cause an immediate error which can be fixed in the development phase), but when combined with incomplete formatting it's a real disaster. There are hundreds of answers on the great site of Stack Overflow, suggesting to escape identifiers the same way as strings. Which would be completely useless and would cause an SQL injection.
Manual formatting is essentially a non-obligatory measure.
First of all, there is an obvious lack of attention case, where proper formatting can be simply forgotten. But there is a really weird case - many PHP users often intentionally refuse to apply any formatting, because up to this day they still separate the data to "clean" and "unclean", "user input" and "non-user input", etc. Thinking that a "safe" data don't need any formatting. Which is a plain nonsense - remember Sarah O'Hara. From the formatting point of view, it's the destination that matters. A developer has to mind the type of SQL literal, not the data source. Is it a string going to the query? It has to be formatted as a string then. No matter if it's from user input or just mysteriously appeared out of nowhere amidst the code execution.
Manual formatting can be separated from the actual query execution by a considerable distance.
The most underestimated and overlooked issue. Yet most essential of them all, as it can spoil all the other rules alone, if not followed.
Almost every PHP user is tempted to do all the "sanitization" in a single place, far away from the actual query execution, and such a wrong approach is a source of innumerable faults alone:
4. A prepared statement is not a silver bullet.
Last, but not least. We all have to remember that data literals are not the only variable parts in the query. Sometimes an identifier or a keyword has to be added as well. Prepared statements are of no help in this case, yet such query parts should have no less protection altogether. Luckily, for either identifiers and keywords, the list of possible variants is always limited, so we can use the whitelisting approach which I described in my answer to the reference question on Stack Overflow, so I won't repeat myself.
To answer your last question - no, a query without variable parts are not vulnerable, as there is no point to inject.