Ex: Say I'm building a...Zelda game? Something where gravity is not needed but one would expect a variety of fixed collision as well as objects. There is an awful lot of tile collisions (walls, anything unmoveable) but also object collisions (enemies, moveable blocks, etc)
Are your enemies tiles? No. So there's no argument here. Could you make your enemies tiles? Sure, in which case tiles-only would be easily doable, although your enemies would have very few attributes in that case. As for movable blocks, those were handled as tiles until Link pushed on them, then the tilemap was modified and a sliding block object was created, allowed to move into place, and then the block object was destroyed and the tilemap was again modified.
Nowhere in any tile collision tutorial has it ever been stated or suggested that objects should not be used at all. Objects are practically a necessity in Game Maker. The point is you should not be flooding your rooms with thousands of instances of objects whose sole roles are to provide collision detection.
A tile has considerably less overhead than an object.
(estimated list based on GMS1, possibly smaller in GMS2)
Code:
background
layer
left
top
width
height
alpha
angle
xscale
yscale
Even invisible objects take up a lot of overhead:
(variables from GMS1)
Code:
alarm[0]
alarm[1]
alarm[2]
alarm[3]
alarm[4]
alarm[5]
alarm[6]
alarm[7]
alarm[8]
alarm[9]
alarm[10]
alarm[11]
bbox_bottom
bbox_left
bbox_right
bbox_top
depth
direction
friction
gravity
gravity_direction
hspeed
id
image_alpha
image_angle
image_blend
image_index
image_number
image_single
image_speed
image_xscale
image_yscale
mask_index
object_index
path_endaction
path_index
path_orientation
path_position
path_positionprevious
path_scale
path_speed
persistent
phy_active
phy_angular_damping
phy_angular_velocity
phy_bullet
phy_col_normal_x
phy_col_normal_y
phy_collision_points
phy_collision_x
phy_collision_y
phy_com_x
phy_com_y
phy_dynamic
phy_fixed_rotation
phy_inertia
phy_kinematic
phy_linear_damping
phy_linear_velocity_x
phy_linear_velocity_y
phy_mass
phy_position_x
phy_position_xprevious
phy_position_y
phy_position_yprevious
phy_rotation
phy_sleeping
phy_speed
phy_speed_x
phy_speed_y
solid
speed
sprite_height
sprite_index
sprite_width
sprite_xoffset
sprite_yoffset
timeline_index
timeline_loop
timeline_position
timeline_running
timeline_speed
visible
vspeed
x
xprevious
xstart
y
yprevious
ystart
It doesn't matter if you don't enable physics. It doesn't matter if you don't assign a sprite. It doesn't matter if you don't use timelines. It doesn't matter if you don't use alarms. As soon as you put an instance in the room, memory is allocated for ALL of those variables and most of those variables take up 8 bytes each. Now multiply that by 1000.