Apply suggestions from code review

Co-authored-by: Vishwa Mehta <vishwa.mehta@ethereum.org>

docs/internals/optimizer.rst

@@ -1398,24 +1398,24 @@ Codegen-Based Optimizer Module
 Currently, the codegen-based optimizer module consists of two distinct steps.
 
 The first step moves literals to the right of commutative binary operators which
-helps exploiting associativity.
+helps exploit associativity.
 
 The second step uses unchecked arithmetic when generating code for incrementing
 the counter variable of specific ``for`` loops. This
 avoids wasting gas by identifying some conditions that guarantee
-that the counter variable cannot overflow. This eliminates the need to use an explicit
+that the counter variable cannot overflow. This eliminates the need to use a verbose
 unchecked arithmetic block inside the loop body to increment the counter variable.
 
 .. _unchecked-loop-optimizer:
 
 Unchecked Loop Increment
 ------------------------
 
-Introduced in Solidity ``0.8.22``, this optimizer step is concerned with identifying
+Introduced in Solidity ``0.8.22``, the overflow check optimization step is concerned with identifying
 the conditions under which the ``for`` loop counter can be safely incremented
 without overflow checks.
 
-This optimization is **only** applied to ``for`` loops with the general form:
+This optimization is **only** applied to ``for`` loops of the general form:
 
 .. code-block:: solidity
 
@@ -1428,13 +1428,13 @@ guarantee that it never overflows.
 The precise requirements for the loop to be eligible for the optimization are as follows:
 
 - The loop condition is a comparison of the form ``i < Y``, for a local counter variable ``i`` and an expression ``Y``.
-- The built-in operator ``<`` is necessarily used in the loop condition. User-defined operators are **not** eligible.
+- The built-in operator ``<`` is necessarily used in the loop condition and is the only operator that triggers the optimization. ``<=`` and the like are intentionally excluded. Additionally, user-defined operators are **not** eligible.
 - The loop expression is a prefix or postfix increment of the counter variable, i.e, ``i++`` or ``++i``.
 - The loop counter is a local declared variable of a built-in integer type.
 - The loop counter is **not** modified by the loop body or by the expression used as the loop condition.
 - The comparison is performed on the same type as the loop counter, meaning that the type of the
   right-hand-side expression is implicitly convertible to the type of the counter, such that the latter
-  is not implicitly widened before comparing.
+  is not implicitly widened before the comparison.
 
 To clarify the last condition, consider the following example: