How is the R-Tree's MBR size determined? Changes to MBR?
First of all, let us have some background. There are variants of Guttman's r-tree that have different splitting heuristics (e.g. Sellis' r+-tree, which involves inserting an item multiple times into a tree; and Beckmann's r*-tree, which takes into account area, margin, overlap). Also, there are variants that are more suitable for higher dimensions (e.g. Berchtold's x-tree, which uses split history and supernodes). You can improve any of the above structures using bulk loading, which can guarantee zero overlap between rectangles at the same level.

Rectangles used typically are minimum bounding rectangles (MBR's) that may fit your data well (if you are using orthonormal rectangles as with data mining), or may have to be used as approximations (if you are trying to detect intersections between polytopes).

You can find MBR's, which are possibly described using upper-left point and lower-right point, by taking extreme value pairs for each dimension.

Note also that points are degenerate rectangles and that we can form MBR's for collections of MBR's.

For example, if we had $P$ = $\{(1, 0), (2, 1), (3, 2), (4, 3)\}$, and right is large $x$ and up is large $y$, an MBR for these points could be $(p_\text{upper-left}, p_\text{lower-right})$ = $((1, 3), (4, 0))$.

There have been attempts to quantify how much time a query on an r-tree takes, but intuitively what is happening is that we may spend more than $O(k \cdot \log(n))$ time for $k$ matches, even though depth is $O(\log(n))$, because we could go down many branches without reaching a match. If you are interested, there are certain operations one could perform on an r-tree that take more time but have clean running time asymptotic values if you include a "look-ahead" query at each node we visit. In the end, however, with a regular r-tree and with regular queries, loosening the MBR's leads to diminished performance.