For a counterpoint, see David R. Hanson's "Is block structure necessary?" (1981) [0] — back in those days, "block structure" meant nested routines with nested scopes — which argues that having instead a proper module system, with explicit control over what's being exported from a module, not only gives a better modularity, decomposition, and encapsulation, but also simplifies both the language's implementation, and the run-time structures it needs (remember displays, and the hardware support for them e.g. x86's ENTER?).

    Block structure is traditionally considered an a priori requirement for algorithmic program-
    ming languages. Most new languages since Algol-60 have block structure. Reasons exist,
    however, to omit the general form of block structure — nested procedure definitions in which
    references to identifiers defined in outer procedures are permitted — from programming
    languages, especially those intended for systems programming applications. This paper
    reviews the concept of block structure and considers its advantages and disadvantages. It
    concludes that, in many cases, a module facility is superior to block structure and should be
    considered in lieu of block structure in future languages.

The traditional way of doing this in C is simply static functions. Every .c file has exactly one non-static function and all the other helper functions are static.