Edit: The OPs comment has been skeptical about the efficiency of the suggested negative circular bound check to improve the algorithm in order do checks whether an arbitrary 2D point lies within a rotated and/or moving rectangle. Fiddling around a bit on my 2D game engine (OpenGL/C++), I supplement my answer by providing a performance benchmark of my algorithm against the OPs current point-in-rectangle-check algorithms (and variations).
I originally suggested to leave the algorithm in place (as it is nearly optimal), but simplify through mere game logic: (1) using a pre-processed circle around the original rectangle; (2) do a distance check and if the point lies within the given circle; (3) use the OPs or other any straightforward algorithm (I recommend the isLeft algorithm as provided in another answer). The logic behind my suggestion is that checking whether a point is within a circle is considerably more efficient than a boundary check of a rotated rectangle or any other polygon.
My initial scenario for a benchmark test is to run a large number of appearing and disappearing dots (whose position changes in every game-loop) in a constrained space that will be filled with around 20 rotating/moving squares. I have published a video (youtube link) for illustration purposes. Notice the parameters: number of randomly appearing dots, number or rectangles. I will benchmark with the following parameters:
OFF: Straightforward algorithm as provided by the OP without circle boundary negative checks
ON: Using per-processed (boundary) circles around the rectangles as a first exclusion check
ON + Stack: Creating circle boundaries at run-time within the loop on the stack
ON + Square Distance: Using square distances as a further optimization to avoid taking the more expensive square root algorithm (Pieter Geerkens).
Here is a summary of the various performances of different algorithms by showing the time it takes to iterate through the loop.
The x-axis shows an increased complexity by adding more dots (and thus slowing down the loop). (For example, at 1000 randomly appearing point checks in a confided space with 20 rectangles, the loop iterates and calls the algorithm 20000 times.) The y-axis shows the time it take (ms) to complete the entire loop using a high resolution performance timer. More than 20 ms would be problematic for a decent game as it would not take advantage of the high fps to interpolate a smooth animation and the game may appear thus 'rugged' at times.
Result 1: A pre-processed circular bound algorithm with a fast negative check within the loop improves the performance by 1900% compared to the regular algorithm (5% of the original loop time without a check). The result holds approximately proportional to the number of iterations within a loop, thus it does not matter if we check 10 or 10000 randomly appearing points. Thus, in this illustration one can increase the number of objects safely to 10k without feeling a performance loss.
Result 2: It has been suggested by a previous comment that the algorithm may be faster but memory intensive. However, note that storing a float for the pre-processed circle size takes merely 4 bytes. This should pose no real issue unless the O.P. plans to run simultaneously 100000+ objects. An alternative and memory efficient approach is to calculate the circle maximum size on the stack within the loop and letting it go out of scope with every iteration and thus having practically no memory usage for some unknown price of speed. Indeed, the result shows that this approach is indeed slower than using a pre-processed circle size, but it still shows a considerable performance improvement of around 1150% (i.e. 8% of the original processing time).
Result 3: I further improve the result 1 algorithm by using squared distances instead of actual distances and thus taking an computationally expensive square root operation. This only sligthtly boosts the performance (2400%). (Note: I also try hash tables for pre-processed arrays for square roots approximations with a similar but slightly worse result)
Result 4: I further check moving/colliding the rectangles around; however, this does not change the basic results (as expected) as the logical check remains essentially the same.
Result 5: I vary the number of rectangles and find that the algorithm becomes even more efficient the less crowdy the space is filled (not shown in demo). The result is also somewhat expected, as the probability decreases for a point to appear within tiny space between a circle and the object's boundaries. On the other extreme, I try to increase the number of rectangles too 100 within the same confined tiny space AND vary them dynamically in size at run time at within the loop (sin(iterator)). This still performs extremely well with increase in performance by 570% (or 15% of the original loop time).
Result 6: I test alternative algorithms suggested on here and find a very slight but not significant difference in performance (2%). The interesting and more simple IsLeft algorithm performs very well with a boost of performance by 17% (85% of the original calculation time) but nowhere near the efficiency of a quick negative check algorithm.
My point is to first consider lean design and game logic, especially when dealing with boundaries and collision events. The OPs current algorithm is already fairly efficient and a further optimization is not as critical as optimizing the underlying concept itself. Moreover, it is good to communicate the scope and purpose of the game, as the efficiency of an algorithm critically depends on them.
I suggest to always attempt to benchmark any complex algorithm during the game design stage as merely looking at the plain code may not reveal the truth about actual run-time performance. The suggested algorithm may not be here even necessary, if, for example, one wishes to merely test if the mouse cursor lies within a rectangle or not, or, when the majority of objects are already touching. If the majority of points checks are within the rectangle, the algorithm will be less efficient. (However, then it would be possible to establish an 'inner circle' boundary as a secondary negative check.) Circle/sphere boundary checks are very useful for any decent collision detection of a large number of objects that have naturally some space in between them.
Rec Points Iter OFF ON ON_Stack ON_SqrDist Ileft Algorithm (Wondra)
(ms) (ms) (ms) (ms) (ms) (ms)
20 10 200 0.29 0.02 0.04 0.02 0.17
20 100 2000 2.23 0.10 0.20 0.09 1.69
20 1000 20000 24.48 1.25 1.99 1.05 16.95
20 10000 200000 243.85 12.54 19.61 10.85 160.58