Ah. I’ve been downvoted... Guess I should’ve been more clear. I was referencing how the OP said COBOL was easier for data layouts. So, not really knowing COBOL, I was asking why. Poor wording.

The feature we’re talking about here is an easy to use version of doing memory layouts like you’d do with C structs and unions. And combined in with that is automatic number formatting. And all of it uses a clean concise layout that’s self documenting.

COBOL structures are better for fixed-length strings than C structs are because C really prefers strings do be null terminated. In C you've got to specify the length of each string, whereas in COBOL the compiler takes care of that for you.

I can even do that better in Lisp over C structs. In my own home-grown dialect. Suppose we have

  struct foo {
    int count;
    char name[16]; /* not null terminated! */
  };

REPL: define an alias name foo for the type with typedef:

  1> (typedef foo (struct foo (count int) (name (array 16 char))))
  #<ffi-type (struct foo (count int) (name (array 16 char)))>

Now put an instance of the Lisp struct into a binary buffer using this FFI type:

  2> (ffi-put #S(foo count 42 name "ABCDABCDABCDABCD") (ffi foo))
  #b'2a00000041424344 4142434441424344 41424344'

Now, recover a new Lisp struct instance from this binary struct:

  3> (ffi-get *2 (ffi foo))
  #S(foo count 42 name "ABCDABCDABCDABCD")

No problem; the FFI type system knows that an "array of char" is different from a null terminated string, and can make it correspond to a Lisp string in both directions.

Now, for fun, let's poke a zero byte into that buffer:

  4> (set [*2 8] 0)
  0
  5> *2
  #b'2a00000041424344 0042434441424344 41424344'

There it is. Now decode:

  6> (ffi-get *2 (ffi foo))
  #S(foo count 42 name "ABCD\xDC00;BCDABCDABCD")

What's that? My UTF-8 decoder treats the 00 as an invalid byte, and maps it into the surrogate pair range U+DCXX. The otherwise optional semicolon was output because the next character in the string is a hex digit.

If that U+DC00 is encoded back, it will reproduce the null byte:

  7> (ffi-put *6 (ffi foo))
  #b'2a00000041424344 0042434441424344 41424344'

COBOL's data types look like they're well-suited to storing fixed-width, hierarchical data, with the format of the data being specified in the data type. The numerical types are oriented toward fixed-point decimal, with explicitly specified levels of precision.

Two variables holding common license plate formats might look like this:

01 LIC-PLATE1 PIC 9A(3)9(3) VALUE '1ABC234'.

01 LIC-PLATE2 PIC 9(3)A(3). VALUE '123ABC'.

[edit: added a newline to separate my examples]

("9" specifies a numerical digit, "A" specifies an alphabetic character, and there are other types that deal with sign, explicit and implicit decimal points, etc).

Assembly deals with memory layouts, but doesn't enforce any kind of higher-level data type, and especially not a human-oriented data specification.

But it is undoubtedly more efficient to do so in COBOL.

COBOL is well described as the language for regular expressions over tables.