No, you don't have to. Remember that spatial subdivision is an optimisation. That means it isn't necessary until you've proven that there is no way your game can run fast enough without it. And optimisations are always prioritisable; what could be optimised with an octree, you might be able to optimise at a lower level, or in another way, so that no spatial subdivision is required. Prematurely optimising is a bad thing. If you've never written a game that required octrees before, chances are you won't have a sense of at what level they actually become a necessity.
Broadly speaking, you're not going to be capable of the same level of processing (read: number of entities in your world) without it, if only for physics purposes. Literally, because of the recursive nature of quad- and octrees, they improve performance by (an) order(s) of magnitude. So you'll probably have to be happy with a relatively simpler world as a result in the meantime (or per se).
Really, spatial subdivision is not such a tough concept to grasp. If you take quadtrees (2D) as a simple example, you can write very basic demo to get familiar with them, using a typical "balls bouncing around screen" type demo as a basis for learning how quadtrees work, and how to apportion collisions using them. You can then directly transfer your knowledge to octrees (3D). That would be my recommended path to a beginner in these.
Anyway, for now, just keep going using a uniform grid, and if things begin to grind, and you've already optimised a good amount in other areas, then look into spatial hashing.