I don't think these trends change much in the timescale of a couple of years.
I use objects all the time, but my programming is in no way "oriented" towards objects. Objects are just a tool, and a pretty useful one because it emphasizes interfaces between parts of the code, which allows large systems to be built without getting overwhelmed by complexity. But to me "Object Oriented Programming" is a bit like "Nail Oriented Roofing".
Even if you think of your programming as "procedural" and "modular", chances are you'll end up using objects naturally. For instance, if you have a type `Image', it is very likely you'll end up having a module that implements functions that operate on Image variables.
In C, the header file would look something like this:
/* ... */
typedef struct {
unsigned char R, G, B, A;
} Color;
typedef struct {
unsigned width, height;
Color *pixel_data;
} Image;
/* Create a new image, allocating memory for its pixel data. */
void create_image(Image *image, unsigned width, unsigned height);
/* Clear an image by setting every pixel to the given color */
void clear_image(Image *image, Color color);
void set_pixel(Image *image, int x, int y, Color color);
Color get_pixel(Image const *image, int x, int y);
void bit_blit(Image *destination, Image const *source, int left_x, int top_y);
/* ... */
I made the switch from C to C++ in 2001. Before then, my C code often looked a lot like this example. If you find yourself writing code in this style, you too are using objects. What are called "member functions" in C++ are essentially the functions that take a first argument of type `Image *'. When it has type `Image const *', it is called a "constant member function". In C++ instead of `set_pixel(&my_image, x, y, my_color);' you would call the member function as `my_image->set_pixel(x, y, my_color);'.
Once you get used to using objects, a lot of your code will naturally be organized this way. However, there are things that in my mind don't fit this model at all. For instance, mathematical functions like `log' don't naturally take a first argument that is a pointer to anything, so it's better to use a free function (i.e., a non-member function) in this case.
A project can be anywhere in the spectrum between not using objects at all and the extreme of organizing all the code as objects. All the projects I have worked on are somewhere in the middle, with lower-level parts of the code using objects only sporadically and higher-level parts being closer to the OOP extreme.
There are good reasons why you may not want to use OOP when dealing with low-level code. For instance, modern hardware is very good at operating on batches of data, either through SIMD instructions or using GPUs. An programmer using OOP in a straight-forward manner can easily write code that does things on a large collection of objects one object at a time, perhaps calling a virtual function on each object (similar to calling a function pointer that is part of the type, in non-OOP terms). That eliminates any possibility of using an SIMD implementation, and therefore results in code that doesn't make optimal use of the computational resources available. An alternative design would have separate arrays for each specific type of object, so instead of calling a virtual function on each object, you can call a function that performs a fixed operation on a collection of objects, and then a SIMD implementation becomes possible. Check out this thread:
http://www.gamedev.net/topic/575076-what-is-data-oriented-programming/